SBCE timing out calls

[cfickes]

I just turned up a new SBCE, and in making inbound test calls, we kept the calls up for 2 to 3 minutes until I disconnected the calls. No issues . Today during testing the calls would disconnect after 30 to 32 seconds. The trace is showing the "BYE" is coming from SBC/CM and not the carrier. What needs to be checked to correct this timeout issue?

 

[cfickes]

SIP flow file

 

[kyle555]

the 200 ok is sent many times. its never acknowledged. thats why the part that sent the bye gave up

 

[cfickes]

I sent the wrong file. It is getting an ACK

 

[cfickes]

Kyle, I pulled a trace on SM and the "BYE" is coming from the CM.

 

[kyle555]

and there's something wrong with that ack getting back to and processed by your cm properly. that's why cm sends a 200ok 9 times before the bye. whatever was in that ack wasnt sufficient for cm to keep the call up. youve got some config issue

 

[cfickes]

Thanks for the information Kyle. I'll start looking at the configs

 

[kyle555]

Without seeing the whole thing, it's tough to guess. far end sip domain in sig group/authoritative domain of the network region of the near/far end nodes of that sig group? Are you using subdomains anywhere? CM is funny in how it deals with that. customer.com should be the authoritative domain of the last NR and most.detailed.subdomain.customer.com should be authoritative earlier. Anytime you exact match a whole domain after the @, the lowest numbered sig group with that authoritative domain in the network region gets triggered.

To say, maybe you set up the call on on sig 100/NR100 and the 200 OK @customer.com with NR1's authoritative domain customer.com and a sig group 1 in customer.com was hijacking the 200OK/ACK sequence such that the sig group that set up the call wasn't the one receiving the OK/ACK part to complete call setup. Just a guess.

Either way, there's no good reason for a 200OK with SDP being sent over and over once RTP was set up. But it's a telltale sign when CM tries the 200 OK every second for a few, then every 2nd second a few times then every 4th second a few times and eventually gives up.

And your traceSM has something on 5061, and your wireshark screencap on 5060/5100. Maybe you mixed up something in the ports too?

 

[cfickes]

We are not using subdomains anywhere. I pulled another trace in SM, and all indications are the SBC is not sending and ACK back to CM.

 

[kyle555]

What kind of SBC? If Avaya, you can traceSBC on it like traceSM, or otherwise trace it there. Is it getting the ACK from the carrier and not returning it to you? etc

 

[cfickes]

It is getting the ACK from the carrier, and as you indicated, it is not returning it. It is an Avaya SBCE.

 

[jimbojimbo]

You might want to check the domain versus IP addresses in the ACK. We've had at least one carrier incorrectly inserting a domain name in PRACK/ACK when everything else is using IP addresses. Had to write a Sigma script to convert the carrier's domain to IP (easier than getting the carrier to fix something).

 

[cfickes]

Come to find out the issue was because we had “SIP packet inspect” turned on in the firewall. This was causing the ACK Request URI to return with a malformed ACK.