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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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:[email protected]:5060 SIP/2.0. >>> Via: SIP/2.0/UDP 10.10.1.1:5060;branch=z9hG4bK3A2284. >>> Remote-Party-ID: "1112223333" <sip:[email protected] >>> >;party=calling;screen=yes;privacy=off. >>> From: "1112223333" <sip:[email protected]>;tag=5745CCC-1C72. >>> To: <sip:[email protected]>. >>> Date: Thu, 17 Dec 2015 19:20:31 GMT. >>> Call-ID: [email protected]. >>> 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:[email protected]: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:[email protected]:5060 SIP/2.0. >>> Via: SIP/2.0/UDP 10.10.1.1:5060;branch=z9hG4bK3C1EC0. >>> From: "1112223333" <sip:[email protected]>;tag=5745CCC-1C72. >>> To: <sip:[email protected]>;tag=1768D8EC-CCDB1323. >>> Date: Thu, 17 Dec 2015 19:20:31 GMT. >>> Call-ID: [email protected]. >>> 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:[email protected]:5060>. >>> Remote-Party-ID: "WIRELESS CALLER" <sip:[email protected] >>> >;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 >>> [email protected] >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >> >> _______________________________________________ >> Users mailing list >> [email protected] >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > [email protected] > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
