[cisco-voip] Incoming CLI Unknown but shows up at bottom of display

Tue Apr 1 08:36:13 EDT 2014

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_turburville at 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 <rthconsultants at 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_turburville at 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:[5060]:
> INVITE sip:44****404900 at 10.168.8.76 SIP/2.0
> Via: SIP/2.0/UDP 10.133.201.81:5060;branch=z9hG4bKac1195424339
> Max-Forwards: 10
> From: <sip:+44****266000 at bnsplc.com;user=phone>;tag=1c1195243906
> To: "**** *404900" <sip:44****404900@*********>
> Call-ID: 11951844583132014104653 at 10.133.201.81
> CSeq: 1 INVITE
> Contact: <sip:+44****266000 at 10.133.201.81: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:[5060]:
> 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****266000 at bnsplc.com;user=phone>;tag=1c1195243906
> Allow-Events: presence
> Remote-Party-ID: <sip:49900 at 10.168.8.76
> >;party=called;screen=yes;privacy=off
> Content-Length: 0
> To: "**** *404900" <sip:44****404900@
> *************>;tag=a4b020a1-c203-404a-ab13-da4aee5de9d8-56767054
> Contact: <sip:44****404900 at 10.168.8.76:5060>
> Call-ID: 11951844583132014104653 at 10.133.201.81
> 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:[5060]:
> SIP/2.0 200 OK
> Date: Mon, 31 Mar 2014 10:46:55 GMT
> From: <sip:+44****266000 at bnsplc.com;user=phone>;tag=1c1195243906
> Content-Length: 0
> To: "**** *404900" <sip:44****404900@**********>
> Call-ID: 11951844583132014104653 at 10.133.201.81
> Via: SIP/2.0/UDP 10.133.201.81:5060;branch=z9hG4bKac1228556740
> CSeq: 2 CANCEL
>
>   On Monday, 31 March 2014, 13:31, "Zoltan.Kelemen at Emerson.com" <
> Zoltan.Kelemen at 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-bounces at puck.nether.net<cisco-voip-bounces at puck.nether.net>]
> *On Behalf Of *Damian Turburville
> *Sent:* Monday, March 31, 2014 2:15 PM
> *To:* cisco-voip at puck.nether.net
> *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
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20140401/5984557c/attachment.html>