[OpenSIPS-Users] Processing calling-name(CNAM) from PRI

Fri Dec 18 18:04:24 CET 2015

Zahid,

You'd have to receive the initial INVITE, place it on hold somehow (not the
SIP RFC sense of "hold", but just "in timeout", "on ice", "go stand in the
corner until I tell you to leave", etc), wait for the INFO message, parse
the information elements you want, recover the initial INVITE, update the
fields you need (RPID/PAI, From, etc) and continue on about your business.
I'm not sure how I would handle the putting-it-on-hold part, or the
subsequent recovery.  A proxy's job is generally to relay messages, and in
this case, you want it to store a message for a period, then recover it and
continue processing.  That's not something a proxy normally does.  So,
that's a tricky one.

- Jeff

On Fri, Dec 18, 2015 at 10:12 AM, Zahid Mehmood <zm23 at columbia.edu> wrote:

> Hi Jeff,
>    Thanks for your response.  From what I understand from Cisco
> documentation, gateway seems to act that way when using H323 but, sadly,
> not for SIP.  I will push Cisco about this.
>
> Assuming the worst, Is there any thing I can try on the proxy side to get
> the desired results?
>
> Regards,
> --
> Zahid
>
>
> On Fri, Dec 18, 2015 at 9:44 AM, Jeff Pyle <jeff.pyle at fidelityvoice.com>
> wrote:
>
>> In Adtran TA900 series gateways (very Cisco-like) I'm able to configure
>> the PRI interface to wait for the FACILITY message before sending the
>> initial INVITE.  When the INVITE does leave the gateway towards the proxy,
>> it has full caller name information.  Perhaps something like this is
>> available on the Cisco.  I hope so, because if not, you're going to have a
>> difficult time integrating the INFO message.
>>
>>
>> - Jeff
>>
>>
>> On Thu, Dec 17, 2015 at 2:53 PM, Zahid Mehmood <zm23 at columbia.edu> wrote:
>>
>>> Hi,
>>>    I am having trouble figuring out how to process the calling-name
>>> coming from the PRI. In my setup, PRI is connected to a Cisco media gateway
>>> which sends traffic to the proxy servers.  Calling name is not coming  in
>>> the ISDN setup message.  It is actually provided in a separate facility
>>> message [1].
>>>
>>> Cisco gateway processes this secondary messages and generates a INFO
>>> message.  Polycom phone sends the 200 ok message but there is no change in
>>> the visible caller id.
>>>
>>> Does anyone have a working example or suggestion of how this is supposed
>>> to work?
>>>
>>> Invite:
>>>
>>> U 2015/12/17 14:20:31.215540 10.10.1.1:50975 -> 10.10.2.2:5060
>>> INVITE sip:10301 at 10.10.2.2:5060 SIP/2.0.
>>> Via: SIP/2.0/UDP 10.10.1.1:5060;branch=z9hG4bK3A2284.
>>> Remote-Party-ID: "1112223333" <sip:1112223333 at 10.10.1.1
>>> >;party=calling;screen=yes;privacy=off.
>>> From: "1112223333" <sip:1112223333 at 10.10.1.1>;tag=5745CCC-1C72.
>>> To: <sip:10301 at 10.10.2.2>.
>>> Date: Thu, 17 Dec 2015 19:20:31 GMT.
>>> Call-ID: 12968BB5-A42A11E5-8062F2AF-E28C686E at 10.10.1.1.
>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat.
>>> Min-SE:  1800.
>>> Cisco-Guid: 0311776101-2754220517-2148597785-1445067520.
>>> User-Agent: Cisco-SIPGateway/IOS-12.x.
>>> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> SUBSCRIBE, NOTIFY, INFO, REGISTER.
>>> CSeq: 101 INVITE.
>>> Max-Forwards: 70.
>>> Timestamp: 1450380031.
>>> Contact: <sip:1112223333 at 10.10.1.1:5060>.
>>> Expires: 180.
>>> Allow-Events: telephone-event.
>>> Content-Type: application/sdp.
>>> Content-Disposition: session;handling=required.
>>> Content-Length: 279.
>>> .
>>> v=0.
>>> o=CiscoSystemsSIP-GW-UserAgent 3918 6190 IN IP4 10.10.1.1.
>>> s=SIP Call.
>>> c=IN IP4 10.10.1.1.
>>> t=0 0.
>>> m=audio 18854 RTP/AVP 0 18 101.
>>> c=IN IP4 10.10.1.1.
>>> a=rtpmap:0 PCMU/8000.
>>> a=rtpmap:18 G729/8000.
>>> a=fmtp:18 annexb=no.
>>> a=rtpmap:101 telephone-event/8000.
>>> a=fmtp:101 0-16.
>>>
>>> Invite messages:
>>>
>>> U 2015/12/17 14:20:31.546310 10.10.1.1:50975 -> 10.10.2.2:5060
>>> INFO sip:10301 at 10.219.136.69:5060 SIP/2.0.
>>> Via: SIP/2.0/UDP 10.10.1.1:5060;branch=z9hG4bK3C1EC0.
>>> From: "1112223333" <sip:1112223333 at 10.10.1.1>;tag=5745CCC-1C72.
>>> To: <sip:10301 at 10.10.2.2>;tag=1768D8EC-CCDB1323.
>>> Date: Thu, 17 Dec 2015 19:20:31 GMT.
>>> Call-ID: 12968BB5-A42A11E5-8062F2AF-E28C686E at 10.10.1.1.
>>> User-Agent: Cisco-SIPGateway/IOS-12.x.
>>> Max-Forwards: 70.
>>> Route: <sip:10.10.2.2;lr=on;ftag=5745CCC-1C72>.
>>> Timestamp: 1450380031.
>>> CSeq: 103 INFO.
>>> Contact: <sip:1112223333 at 10.10.1.1:5060>.
>>> Remote-Party-ID: "WIRELESS CALLER" <sip:1112223333 at 10.10.1.1
>>> >;party=calling;screen=no;privacy=off.
>>> Content-Length: 0.
>>> .
>>>
>>>
>>> Best Regards,
>>>
>>> --
>>> Zahid
>>>
>>> [1]
>>> http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/sip/configuration/15-mt/sip-config-15-mt-book/voi-sip-isdn.html#GUID-53D5C9AB-AAC4-4178-8158-0DAEFB5BC33E
>>> (figure 2 is close to what we are seeing)
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20151218/56e14135/attachment.htm>