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@192.168.5.97>;tag=m29tUHH087vFr To: <sip:307000421221028600@192.168.5.17>;tag=p9D7Npj3amv3j Call-ID: 953485a8-d9b6-4c36-a54d-01fab395ad48 CSeq: 75805518 INVITE Contact: <sip:307000421221028600@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@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@212.232.17.60>;tag=as703def00 To: <sip:+421221028600@212.232.17.77>;tag=XB02p6tZSjvFN Call-ID: 2598c37260ec91283d70ac220f32c5cf@212.232.17.60:5060 CSeq: 102 INVITE Contact: <sip:+421221028600@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org