Hello community, We have this very odd issue: Incoming call from external number to internal extension that is forwarded to another external number is connecting, but has no audio. Phone A (any external number, but in this example +359889610844) dials +496152930142; this goes to our internal number Phone B. If Phone B doesn’t answer in 5 seconds (usually higher value, but we set it to 5 for the test) it is forwarded to Phone C (again any external number, but in the example +359885890203). While Phone B is ringing Phone A hears the ringback tone. As soon as the 5 seconds expire and the call is sent to Phone C, Phone A stops hearing anything. Phone C can still answer the call, but both Phone A and Phone C don’t hear anything. If Phone A is internal number and dials the other internal number Phone B, then the call reaches the external Phone C with no problem and call is successful with two-way audio. We reviewed debugs from CUBE and here is what we see: 1 Initial INVITE comes from ITSP as: INVITE sip:+firstname.lastname@example.org:5060;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 126.96.36.199:5060;branch=z9hG4bK6711e1970bb02b8a77b6edf2802e011d.6122ffbd Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr> Max-Forwards: 60 To: +496152930142 <sip:+email@example.com;transport=udp;user=phone> From: <sip:+firstname.lastname@example.org;transport=udp;user=phone>;tag=c457483f Call-ID: email@example.com Contact: <sip:dbkzX2uNsvwNYjMBqLWmSuVnZlOZZz9HSWX2vNEgXPWahTZ3kAyirEc93UAYofaW@th1> Supported: 100rel,199,histinfo,timer Session-Expires: 1800;refresher=uac CSeq: 317357 INVITE Allow: ACK, BYE, CANCEL, INFO, INVITE, MESSAGE, NOTIFY, OPTIONS, PRACK, REGISTER, UPDATE Min-SE: 900 P-Asserted-Identity: <sip:+firstname.lastname@example.org;user=phone> P-Called-Party-ID: <sip:+email@example.com;user=phone> Content-Type: application/sdp Content-Disposition: session Content-Length: 434 v=0 o=- 1197381055 1197381056 IN IP4 188.8.131.52 s=on transit c=IN IP4 184.108.40.206 t=0 0 m=audio 16476 RTP/AVP 8 116 0 108 102 18 4 109 a=rtpmap:8 PCMA/8000 a=rtpmap:116 telephone-event/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:108 AMR/8000 a=fmtp:108 mode-change-neighbor=1;mode-change-period=2;mode-change-capability=2 a=rtpmap:102 AMR/8000 a=rtpmap:18 G729/8000 a=rtpmap:4 G723/8000 a=rtpmap:109 G726-16/8000 a=ptime:20 2 The call is sent to our CUCM and the internal extension rings. At this point the caller hears ringback tone. 3 The call is forwarded after 5 seconds (as seen from the underlined time). 4 We send this INVITE out to ITSP for the forwarded call: INVITE sip:+firstname.lastname@example.org:5060 SIP/2.0 Via: SIP/2.0/TCP 192.168.178.2:5060;branch=z9hG4bKC8E1025B6 From: <sip:email@example.com>;tag=E71F3532-1062 To: <sip:+firstname.lastname@example.org> Date: Tue, 17 Sep 2019 07:34:36 GMT Call-ID: 6EE9F5BA-D85411E9-9E98E977-7E77540F@192.168.178.2 Supported: 100rel,timer,resource-priority,replaces,sdp-anat Cisco-Guid: 2550764416-0000065536-0000009094-0197689610 User-Agent: Cisco-SIPGateway/IOS-16.10.1a Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER CSeq: 101 INVITE Timestamp: 1568705676 Contact: <sip:email@example.com:5060;transport=tcp> Expires: 900 Allow-Events: telephone-event Max-Forwards: 57 P-Asserted-Identity: <sip:firstname.lastname@example.org> Session-Expires: 1800 Content-Type: application/sdp Content-Disposition: session;handling=required Content-Length: 250 v=0 o=CiscoSystemsSIP-GW-UserAgent 4242 3444 IN IP4 192.168.178.2 s=SIP Call t=0 0 m=audio 22006 RTP/AVP 8 0 101 c=IN IP4 192.168.178.2 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 5 When the ringback is expected we receive this 183 SESSION PROGRESS message from ITSP: SIP/2.0 183 Session Progress Via: SIP/2.0/TCP 192.168.178.2:5060;received=220.127.116.11;branch=z9hG4bKC8E11144A Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr> To: <sip:+email@example.com>;tag=9dd94eeb From: <sip:firstname.lastname@example.org>;tag=E71F3532-1062 Call-ID: 6EE9F5BA-D85411E9-9E98E977-7E77540F@192.168.178.2 Contact: <sip:V5e8BU/ZdShUM5xuxol6cBsKrAACOtdLLbJxR4hinOuRo8SV1aSW8oljXGHYx5IjyWqI@th1> Supported: 100rel CSeq: 102 INVITE Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REGISTER, UPDATE Reason: TSSI;cause=0 Session-ID: 3a85beb51b60bf12079678d4dcee3e0a Content-Type: application/sdp Content-Disposition: session Content-Length: 237 v=0 o=- 3560920190817093400 1500643355 IN IP4 18.104.22.168 s=on transit c=IN IP4 22.214.171.124 t=0 0 m=audio 11370 RTP/AVP 8 101 a=rtpmap:8 PCMA/8000 a=fmtp:8 vad=no a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv At this point the caller stops hearing anything. 6 The call is answered by the destination of the forwarding, but both parties can’t hear anything. From here on the two phones wait for 5-10 seconds of the silence and they hang up. The call is disconnected normally. From signalling point of view everything looks just fine for me. The call reaches the destination, it is answered, then disconnected all normally. But the media portion is lost somewhere along the way. What I sent as questions to the ITSP is: The initial INVITE (1) comes from your end with TO field “<sip:+496152930142@de;transport=udp;user=phone>”, where in all other messages + the second INVITE for the forwarded call (4) we send TO field like this “To: <sip:+email@example.com>”. sip-trunk.telekom.de is the destination for out trunk pointing to you and we send everything with this suffix. Our question is: Is this normal and expected behaviour? Does this work with all your other clients? The media IP in the initial INVITE (1) and the 183 SESSION PROGRESS for the forwarded (5) call you sent us are different. I assume they both are resolved from sip-trunk.telecom.de. Our question here is: Is it normal to change the media IP for the same call? Can you keep the same media IP for the entire call? I am suspecting that the issue might be with one of those things, but I am not sure. Does anybody have a clue for something in the CUBE, which might be causing the issue? I am attaching the running config and debugs ccsip messages and voice ccapi. Any help will be greatly appreciated!
... View more
I am working on a problem with 10.5 cluster in Mixed mode using the old type: USB token + CTL client. After an upgrade last year certain types of phones can't be switched to Secure profile. All 79XX phones are staying unregistered, while 8821 phones go Rejected. All other types (mostly 88XX) are working just fine. Both problematic types are running latest firmware. Deleting ITL+CTL doesn't help, even factory reset on 7941 didn't help. I made a packet capture towards the 7941 phone and this is what I see:
The phone is trying to register with the Subscriber where all certificates are valid, but I noticed that CAPF and TVS certs are expired long ago on the Publisher, long before the upgrade to 10.5. After that upgrade the problem with 79XX started. Strange thing is that other types even those that i switched yesterday are fine.
I have several questions here:
1. Is the expired TVS certificate causing the problem?
2. Is it safe to regenerate it and should I do something with the CTL client or just from OS Administration? - I read a lot of articles here and I believe that regenerating only TVS on only one server is safe and I can't lock my phones, but would like to verify.
3. If I regenerate TVS after restarting TVS and TFTP services clusterwide, should I restart all phones or just the ones that don't want to accept the Security profile?
4. What should I do with the expired CAPF certificate? It is expired since 2014 and I didn't have any problems until now.
Any help would be greatly appreciated!
... View more
Thank you for your response. There's no CUBE, it's direct SIP to the SP, but I believe it is the same. The thing is that the issue happens with incomming call so the 180 is being sent FROM CUCM and not to it.
The INVITE has 100rel supported, and not require, but I can give that a shot.
INVITE sip:firstname.lastname@example.org:5060;user=phone SIP/2.0 Via: SIP/2.0/UDP 10.10.34.97:5060;branch=z9hG4bKknrlnr207g2mghers8b0.1 Call-ID: SDifk9601-6bd818f2f36e289822e4d1fa0c0d3eb1-ags9010030 From: <sip:email@example.com;user=phone>;tag=SDifk9601-3g63ux3u-CC-1000 To: <sip:firstname.lastname@example.org;user=phone> CSeq: 1 INVITE Contact: <sip:email@example.com:5060;transport=udp> Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,REGISTER,INFO,PRACK,SUBSCRIBE,NOTIFY,UPDATE,MESSAGE,REFER User-Agent: United.Com Supported: 100rel Max-Forwards: 69 Content-Length: 235 Content-Type: application/sdp v=0 o=ucom 5281119 5281119 IN IP4 10.10.34.97 s=Sip Call c=IN IP4 10.10.34.97 t=0 0 m=audio 20122 RTP/AVP 8 0 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20
... View more
I am having the following strange CFNA problem:
Call flow: ITSP - SIP - CUCM - SCCP - Phone A (forward after 10 seconds to phone B, forward after 10 seconds to phone C, then back to A).
Carrier sends INVITE with EO; CUCM responds with 100 and 180 without SDP. 10 seconds later CUCM sends UPDATE for the call being forwarded to phone B, but ITSP throws back 491 Request pending. User experience is the caller keeps constant ringing where the called number (phone B or C) can pick up the call, but hears nothing.
I assume that the ITSP expects SDP with 180 (or 183) to establish the session before we can Update it. Is there a way to force CUCM use SDP with 180 or use 183 with SDP to go around this problem. Once again no CUBE involved. Or shuold the carrier be able to process the UPDATE even without the SDP from CUCM.
SIP trunk is direct between CUCM and carrier and has MTP required checked.
CUCM is 10.5, recently upgraded from 8.5. Issue started after the upgrade. It is most probably a parameter that is new in 10.5, but can't seem to find it.
Thank you in advance!
... View more