cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3137
Views
35
Helpful
27
Replies

CME 11 - Incomming call drop after 7 seconds

s4siddiqui
Level 1
Level 1

Hello all...can some one please advice what is the cause of the call getting dropped right at 7 seconds mark...outgoing is no issue....I am struggling with this system and need help. sh run attached.

 

 

27 Replies 27

What?? Shut up man. Saved that one for some other time. LOL!
Thanks for chiming in mate. Appreciate it and your pcap issue is still pending with me, I haven't forgot. I just got tied up. I will send you a DM shortly to discuss.

Nipun,

Call ID 161 is not from ITSP to gateway. ITSP is not talking to CCAPI. This is the leg from the SIP layer to CCAPI. Hence it is the gateway that is sending the disconnect not the ITSP. I analysed the logs in detailed below.

Please rate all useful posts

Yes, you are right. Wrong choice of words from me in the explanation. I analyzed the last logs as well and added them before your post.
ACK is never sent by ITSP and op has a firewall doing NAT so a pcap from egress of that was requested by me.

And yes, 161 is b/w the sip stack and ccapi and is always local but it is the actual external call leg at a high level view.

So effectively what I meant was that a disconnect on the SIP layer for the leg b/w the ITSP and GW is relayed down to ccapi and the leg is marked as 161 which is seen in the logs.

Hi there...

So the NAT is happening on the firewall, initially i thought its the FW not doing the NATing properly, I opened up a ticket with Palo Alto and they dig deeper and found out that PA is doing the NAT properly, there is nothing wrong in it...the said the CME is saying BYE and dc the call.

pardon me, there is a lot of stuff you guys talking that I just don't understand....lol...I am brand new to voice platform...what should I be saying to ITSP now? I know they checked everything at their end earlier....I don't know.

No worries. Can you collect a pcap from the ingress and egress of your firewall for the issue ? It would tell us what is happening.

these threads here are not allowing the attachment of pcaps.

Attach them as a .txt

Hi,

We can try something also. Lets modify your contact header to have your public IP using sip profiles

Configure the following 

#conf t

voice class sip-profiles 10

response 200 sip-header Contact modify “<sip:(.*)@192.168.70.254:5060>" "<sip:\1@64.114.20.54:5065>"

 

Then apply it to the inbound dial-peer which matched the called number from ITSP

dial-peer voice 1 voip

voice-class sip profiles 10

 

Test again and if it fails please send the following logs

debug ccsip info

debug ccsip mess

Please rate all useful posts

When I mentioned earlier that the ITSP dial peer usually has SIP bound to the ITSP-facing interface I was thinking something along these lines. That the ITSP is declining to respond to OK messages from an IP address they do not recognize. I didn't realize the router was behind a NATed firewall.

 

I will keep your command handy for future reference. You are 'da bomb!

 

Maren

so I initiated some calls today and asked the ITSP to do a trace for me, they told me that the message 200 is coming from an internal IP.

I modified voice class sip profile as Ayodegi advised and called that profile in the inbound dial-peer and the issue is resolved...you are the MAN and a scholar! thanks a bunch...thanks to all as well!.

So that means either your firewall was not nating corrctly or you were not aware if your firewall can nat or not.

actually thats a no. I have configured my firewall to do the NAT with SIP ALG disabled (tried with enabling) there are a few application overrides and other settings, but still the FW was missing this NAT (apparently a known issue with CME integration with Palo Alto) before that I was doing it it my ASA which had no issues.

Ok. So NAT alone does not change the L7 payload information which in case of SIP are the embedded IP addresses. What you did on router with SIP profile is not ALG is just SIP normalisation which achieves the same thing that ALG does or which should have been done for an ALG or you edge device.