01-09-2015 04:35 AM - edited 03-17-2019 01:32 AM
Hello,
Working environment with ITSP - CUBE - CM(8.6).
"All of a a sudden" I have incoming call callerids appearing on 9971 phones in the format:
CallingNumber@itspserver.itspdomain
Callerid ids on all other phones are displaying OK (without the @ ... part).
Any clues would be most welcome.
Thanks.
Solved! Go to Solution.
01-09-2015 07:04 AM
OK, you can configure this on the dial-peer level. So that it only changes the pai for inbound calls to cucm
Add the command below to the outbound dial-peer to cucm
dial-peer voice xxxx voip
voice-class sip asserted-id pai
01-09-2015 05:08 AM
Are the other phones SIP? or are they SCCP phones. Can you send us a debug ccsip messages from your cube. Please include calling and called number
01-09-2015 05:43 AM
Hello,
all other phones are SCCP.
Attached debug.
697478XXXX is the calling no, from PSTN
210270XXXX is the called no
0697478XXXX@ims.itsp.gr is shown on the phone
Tested 7945 and 9971 having same number. On any incoming call the 7945 will display the correct callerid while the 9971 will show the uri.
Also tested 6921 SIP and it displays correctly. Which means, so far have seen it only on my 9971.
01-09-2015 06:13 AM
The reason this is happening is because in the INVITE sent by your CUBE to CUCM, there is no "pai" or "remote-party id" present. hence the only header that is used to present CLI is the From header
+++++++++
Sent:
INVITE sip:6912@XXX.XXX.14.11:5064 SIP/2.0
Via: SIP/2.0/UDP XXX.XXX.14.25:5060;branch=z9hG4bKAAD112068
From: <sip:0697478XXXX@ims.itsp.gr>;tag=110D1DF4-A13
To: <sip:6912@XXX.XXX.14.11>
Date: Fri, 09 Jan 2015 12:51:06 GMT
Call-ID: 2CA7B0E-973511E4-8530D6B4-9B37F0D5@XXX.XXX.14.25
From the trace above you can see that the From header matches what you see on the display of the phone.
The question is why is CUBE not sending a Remote-Party-ID or PAI?
lets try this..
conf t
voice service voip
sip
asserted-id pai
test again and send me the logs
01-09-2015 07:01 AM
Well, the invite now contains a line:
P-Asserted-Identity: <sip:+30697478xxxx@XXX.XXX.14.25>
And I got Callerid on the phone as:+30697478xxxx
So almost there, but had to revert back, it seems I could not do outgoing calls, the command asserted-id pai must have somehow affected them. Investigating this.
INVITE sip:5367@XXX.XXX.14.11:5063 SIP/2.0
Via: SIP/2.0/UDP xxx.xxx.14.25:5060;branch=z9hG4bKAB24E61F
From: <sip:+30697478XXXX@ims.itsp.gr>;tag=11501326-1F92
To: <sip:5367@xxx.xxx.14.11>
Date: Fri, 09 Jan 2015 14:04:14 GMT
Call-ID: 3A545FD0-973F11E4-8F1FD6B4-9B37F0D5@xxx.xxx.14.25
Supported: timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0978588092-2537492964-2400835252-2604134613
User-Agent: Cisco-SIPGateway/IOS-15.3.3.M
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 1420812254
Contact: <sip:+30697478XXXX@XXX.XXX.14.25:5060>
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 65
Alert-Info: <http://www.huawei.com/ring/>;info=pattern1
P-Asserted-Identity: <sip:+30697478xxxx@XXX.XXX.14.25>
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 238
v=0
o=CiscoSystemsSIP-GW-UserAgent 7589 8509 IN IP4 xxx.xxx.14.25
s=SIP Call
c=IN IP4 XXX.XXX.14.25
t=0 0
m=audio 22726 RTP/AVP 18 8
c=IN IP4 XXX.XXX.14.25
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=ptime:20
01-09-2015 07:04 AM
OK, you can configure this on the dial-peer level. So that it only changes the pai for inbound calls to cucm
Add the command below to the outbound dial-peer to cucm
dial-peer voice xxxx voip
voice-class sip asserted-id pai
01-09-2015 07:49 AM
Indeed it worked by putting it at the dial-peer level.
Great stuff, thanks a lot for your help!
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide