[Freeswitch-users] RPID to PAI translation

Tomáš Boros boros at vmtele.com
Fri May 22 13:17:45 MSD 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20150522/4df0dff1/attachment.html 


Join us at ClueCon 2016 Aug 8-12, 2016
More information about the FreeSWITCH-users mailing list