Tomáš Boros
2015-05-22 09:17:45 UTC
Hello,
we have the following problem.
On profile, which connects to the provider we use P-Asserted-Identity
for identification.
In the internal line, we use Remote-Party-ID for identification.
The following problem occurs:
When doing calls, Invites are correctly translated from PAI to RPID, but
when a 200 OK arrives from our Internal network, it has a
Remote-Party-ID and is translated to a P-Asserted-Identity, but the
number is changed.
I am attaching SIP messages:
recv 1167 bytes from udp/[192.168.5.17]:5060 at 10:26:06.319229:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.5.97;rport=5060;branch=z9hG4bK5mNSKt220vF5K
Record-Route: <sip:192.168.5.66;lr=on;ftag=m29tUHH087vFr;did=01a.d76>
Record-Route: <sip:192.168.5.18;lr=on;did=01a.bf7>
From: "00421800123993"
<sip:***@192.168.5.97>;tag=m29tUHH087vFr
To: <sip:***@192.168.5.17>;tag=p9D7Npj3amv3j
Call-ID: 953485a8-d9b6-4c36-a54d-01fab395ad48
CSeq: 75805518 INVITE
Contact: <sip:***@192.168.5.94:5060;transport=udp>
User-Agent: VMTele-SBC
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 278
X-FS-Support: update_display,send_info
*Remote-Party-ID:
<sip:+***@212.232.17.77>;party=calling;screen=yes;privacy=off*
v=0
o=VMTele-SBC 1432264463 1432264464 IN IP4 192.168.5.94
s=VMTele-SBC
c=IN IP4 192.168.5.94
t=0 0
m=audio 18702 RTP/AVP 8 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20
a=rtcp:18703 IN IP4 192.168.5.94
In debug logs I can see:
2015-05-22 10:26:06.328812 [ALERT] sofia.c:1198
sofia/core-profile/307000421221028600 Same Callee ID "Outbound Call"
<307000421221028600>
send 1030 bytes to udp/[212.232.17.60]:5060 at 10:26:06.340758:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.232.17.60:5060;branch=z9hG4bK4365798a;rport=5060
From: <sip:+***@212.232.17.60>;tag=as703def00
To: <sip:+***@212.232.17.77>;tag=XB02p6tZSjvFN
Call-ID: ***@212.232.17.60:5060
CSeq: 102 INVITE
Contact: <sip:+***@212.232.17.77:5060;transport=udp>
User-Agent: VMTelecomSBC
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, PRACK, NOTIFY
Require: timer
Supported: precondition, 100rel, timer, path, replaces
Allow-Events: talk, hold, conference, refer
Session-Expires: 800;refresher=uac
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 257
*P-Asserted-Identity: "VIPTel" <sip:***@212.232.17.77>*
v=0
o=VMTele-SBC 1432250761 1432250762 IN IP4 212.232.17.77
s=VMTele-SBC
c=IN IP4 212.232.17.77
t=0 0
m=audio 32404 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp:32405 IN IP4 212.232.17.77
I have made tests with PAI<-> PAI too, I mean I have used
P-Asserted-Identity instead of Remote-Party-ID in 200 OK, and in such a
case it worked correctly. Received number and name was forwarded to the
other leg.
The problem only occurs, when the RPID is in the incoming 200 OK.
Do you think its a bug? I have pass-callee-id set to true on both
profiles and I use pai and rpid as in sip_cid_type accordingly.
we have the following problem.
On profile, which connects to the provider we use P-Asserted-Identity
for identification.
In the internal line, we use Remote-Party-ID for identification.
The following problem occurs:
When doing calls, Invites are correctly translated from PAI to RPID, but
when a 200 OK arrives from our Internal network, it has a
Remote-Party-ID and is translated to a P-Asserted-Identity, but the
number is changed.
I am attaching SIP messages:
recv 1167 bytes from udp/[192.168.5.17]:5060 at 10:26:06.319229:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.5.97;rport=5060;branch=z9hG4bK5mNSKt220vF5K
Record-Route: <sip:192.168.5.66;lr=on;ftag=m29tUHH087vFr;did=01a.d76>
Record-Route: <sip:192.168.5.18;lr=on;did=01a.bf7>
From: "00421800123993"
<sip:***@192.168.5.97>;tag=m29tUHH087vFr
To: <sip:***@192.168.5.17>;tag=p9D7Npj3amv3j
Call-ID: 953485a8-d9b6-4c36-a54d-01fab395ad48
CSeq: 75805518 INVITE
Contact: <sip:***@192.168.5.94:5060;transport=udp>
User-Agent: VMTele-SBC
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 278
X-FS-Support: update_display,send_info
*Remote-Party-ID:
<sip:+***@212.232.17.77>;party=calling;screen=yes;privacy=off*
v=0
o=VMTele-SBC 1432264463 1432264464 IN IP4 192.168.5.94
s=VMTele-SBC
c=IN IP4 192.168.5.94
t=0 0
m=audio 18702 RTP/AVP 8 101 13
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20
a=rtcp:18703 IN IP4 192.168.5.94
In debug logs I can see:
2015-05-22 10:26:06.328812 [ALERT] sofia.c:1198
sofia/core-profile/307000421221028600 Same Callee ID "Outbound Call"
<307000421221028600>
send 1030 bytes to udp/[212.232.17.60]:5060 at 10:26:06.340758:
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.232.17.60:5060;branch=z9hG4bK4365798a;rport=5060
From: <sip:+***@212.232.17.60>;tag=as703def00
To: <sip:+***@212.232.17.77>;tag=XB02p6tZSjvFN
Call-ID: ***@212.232.17.60:5060
CSeq: 102 INVITE
Contact: <sip:+***@212.232.17.77:5060;transport=udp>
User-Agent: VMTelecomSBC
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, PRACK, NOTIFY
Require: timer
Supported: precondition, 100rel, timer, path, replaces
Allow-Events: talk, hold, conference, refer
Session-Expires: 800;refresher=uac
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 257
*P-Asserted-Identity: "VIPTel" <sip:***@212.232.17.77>*
v=0
o=VMTele-SBC 1432250761 1432250762 IN IP4 212.232.17.77
s=VMTele-SBC
c=IN IP4 212.232.17.77
t=0 0
m=audio 32404 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=rtcp:32405 IN IP4 212.232.17.77
I have made tests with PAI<-> PAI too, I mean I have used
P-Asserted-Identity instead of Remote-Party-ID in 200 OK, and in such a
case it worked correctly. Received number and name was forwarded to the
other leg.
The problem only occurs, when the RPID is in the incoming 200 OK.
Do you think its a bug? I have pass-callee-id set to true on both
profiles and I use pai and rpid as in sip_cid_type accordingly.
--
Tomáš Boros
Tomáš Boros