So by CNAM dips, what I mean is that in telephony, it is generally the responsibility of the terminating carrier (the carrier terminating the inbound call to your peer) to provide the lookup CLID and pass that on to your peer (http://www.voip-info.org/wiki/view/CNAM). If they don't do the lookup, all you'll get is the calling party number. Generally, SIP providers charge extra for this service (on your bill the line item might read like 'CNAM lookup service XXXX queries').
Your trunk looks good. I would verify that your provider is passing the CLID name. Thanks, Ryan Huff On Tue, Apr 1, 2014 at 4:45 AM, Damian Turburville <d_turburvi...@yahoo.com>wrote: > I'm afraid I don't know about the CNAM dips, what exactly do you mean? > Here are the screenshots for the SIP trunks though. I wouldn't be > surprised if these are not set up optimally as it was done in rather a > hurry and since it works I haven't revisited it. > Thanks > On Tuesday, 1 April 2014, 0:07, Ryan Huff <rthconsulta...@gmail.com> > wrote: > So you're getting the calling party number, but not the calling party > name? > > If that's the case, is your SIP provider doing CNAM dips for termination? > > Can you provide a screenshot of your trunk configuration between the cucm > and SBC from the cucm's perspective? > > Thanks, > > Ryan > > Sent from my iPhone > > On Mar 31, 2014, at 10:30 AM, Damian Turburville <d_turburvi...@yahoo.com> > wrote: > > Unfortunately we do not have a CUBE, the calls are delivered from our > carrier via SIP to our SBC and then over a direct SIP trunk to CUCM6. > I just dont understand why the call shows as Unknown Number and yet the > caller number is shown at the bottom of the screen (see attached photo) > Here are some of the SIP traces from RTMT (I have anonymised the data a > bit) > > 03/31/2014 11:46:55.114 CCM|//SIP/SIPUdp/wait_UdpDataInd: Incoming SIP UDP > message size 868 from 10.133.201.81:: > INVITE sip:firstname.lastname@example.org SIP/2.0 > Via: SIP/2.0/UDP 10.133.201.81:5060;branch=z9hG4bKac1195424339 > Max-Forwards: 10 > From: <sip:+44****266...@bnsplc.com;user=phone>;tag=1c1195243906 > To: "**** *404900" <sip:44****404900@*********> > Call-ID: email@example.com > CSeq: 1 INVITE > Contact: <sip:+firstname.lastname@example.org:5060> > Supported: 100rel,timer > Allow: ACK,BYE,CANCEL,INFO,INVITE,OPTIONS,PRACK,REFER,NOTIFY,UPDATE > Session-Expires: 900;refresher=uac > Min-SE: 60 > User-Agent: Mediant 4000/v.6.60A.265.010 > Accept: application/media_control+xml,application/sdp,multipart/mixed > Content-Type: application/sdp > Content-Length: 201 > > v=0 > o=BroadWorks 1195087044 1195087027 IN IP4 10.133.201.81 > s=- > c=IN IP4 10.133.201.81 > t=0 0 > m=audio 21860 RTP/AVP 8 101 > a=rtpmap:8 PCMA/8000 > a=rtpmap:101 telephone-event/8000 > a=fmtp:101 0-15 > > 03/31/2014 11:46:55.170 CCM|//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP > UDP message to 10.133.201.81:: > SIP/2.0 180 Ringing > Date: Mon, 31 Mar 2014 10:46:55 GMT > Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, > SUBSCRIBE, NOTIFY, PUBLISH > From: <sip:+44****266...@bnsplc.com;user=phone>;tag=1c1195243906 > Allow-Events: presence > Remote-Party-ID: <sip:email@example.com > >;party=called;screen=yes;privacy=off > Content-Length: 0 > To: "**** *404900" <sip:44****404900@ > *************>;tag=a4b020a1-c203-404a-ab13-da4aee5de9d8-56767054 > Contact: <sip:firstname.lastname@example.org:5060> > Call-ID: email@example.com > Via: SIP/2.0/UDP 10.133.201.81:5060;branch=z9hG4bKac1228556740 > CSeq: 2 INVITE > > 03/31/2014 11:46:55.623 CCM|//SIP/SIPUdp/wait_SdlSPISignal: Outgoing SIP > UDP message to 10.133.201.81:: > SIP/2.0 200 OK > Date: Mon, 31 Mar 2014 10:46:55 GMT > From: <sip:+44****266...@bnsplc.com;user=phone>;tag=1c1195243906 > Content-Length: 0 > To: "**** *404900" <sip:44****404900@**********> > Call-ID: firstname.lastname@example.org > Via: SIP/2.0/UDP 10.133.201.81:5060;branch=z9hG4bKac1228556740 > CSeq: 2 CANCEL > > On Monday, 31 March 2014, 13:31, "zoltan.kele...@emerson.com" < > zoltan.kele...@emerson.com> wrote: > Hi Damian, > > A SIP debug on your CUBE can clarify which fields you are getting and then > you could use voice class sip-profile to modify some sip headers on your > CUBE to fix it. > This assuming you have a CUBE controlled by you between the CUCM cluster > and the provider. > > Lacking that you could pull the SIP traces from the CUCM cluster and have > your provider send the appropriate fields. > > Regards, > > *Zoltan Kelemen* > Global Communications and Information Security > Implementation Engineering > w: +40 374 132356 | m: +40 757 039093 > > *From:* cisco-voip > [mailto:cisco-voip-boun...@puck.nether.net<cisco-voip-boun...@puck.nether.net>] > *On Behalf Of *Damian Turburville > *Sent:* Monday, March 31, 2014 2:15 PM > *To:* email@example.com > *Subject:* [cisco-voip] Incoming CLI Unknown but shows up at bottom of > display > > Hi, > Bit of a weird one here. Recently transferred PSTN services to a SIP > carrier, so incoming calls are now coming through a SIP trunk from an SBC. > Incoming calls are showing up as "Unknown Number" but at the bottom of the > display, just above the softkeys it shows the correct CLI. Any ideas? > CUCM 6.1 > 7942 Phone > > > Damian > > > > <20140331_150827.jpg> > > _______________________________________________ > cisco-voip mailing list > firstname.lastname@example.org > https://puck.nether.net/mailman/listinfo/cisco-voip > > > >
_______________________________________________ cisco-voip mailing list email@example.com https://puck.nether.net/mailman/listinfo/cisco-voip