[Freeswitch-users] RPID to PAI translation
Tomáš Boros
boros at vmtele.com
Fri May 22 14:13:16 MSD 2015
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
On 22.05.2015 11:17, Tomáš Boros wrote:
> 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:00421800123993 at 192.168.5.97>;tag=m29tUHH087vFr
> To: <sip:307000421221028600 at 192.168.5.17>;tag=p9D7Npj3amv3j
> Call-ID: 953485a8-d9b6-4c36-a54d-01fab395ad48
> CSeq: 75805518 INVITE
> Contact: <sip:307000421221028600 at 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:+421221028600 at 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:+421800123993 at 212.232.17.60>;tag=as703def00
> To: <sip:+421221028600 at 212.232.17.77>;tag=XB02p6tZSjvFN
> Call-ID: 2598c37260ec91283d70ac220f32c5cf at 212.232.17.60:5060
> CSeq: 102 INVITE
> Contact: <sip:+421221028600 at 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:307000421221028600 at 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
>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150522/91414ab6/attachment.html
Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users
mailing list