Discussion:
[Freeswitch-users] RPID to PAI translation
Tomáš Boros
2015-05-22 09:17:45 UTC
Permalink
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.
--
Tomáš Boros
Tomáš Boros
2015-05-22 10:13:16 UTC
Permalink
Ok,
I have found it in the sources of mod_sofia.

In function sofia_update_callee_id the function parses the call ID only
from the P-asserted-identity, so RPID is ignored.
Can be this posted to Jira as feature request?

Thank you,
Thomas
Post by Tomáš Boros
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.
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.
------------------------------------------------------------------------
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"
Call-ID: 953485a8-d9b6-4c36-a54d-01fab395ad48
CSeq: 75805518 INVITE
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
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
2015-05-22 10:26:06.328812 [ALERT] sofia.c:1198
sofia/core-profile/307000421221028600 Same Callee ID "Outbound Call"
<307000421221028600>
------------------------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 212.232.17.60:5060;branch=z9hG4bK4365798a;rport=5060
CSeq: 102 INVITE
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
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
_________________________________________________________________________
http://www.freeswitchsolutions.com
Official FreeSWITCH Sites
http://www.freeswitch.org
http://confluence.freeswitch.org
http://www.cluecon.com
FreeSWITCH-users mailing list
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
Loading...