Super long delay in some outbound calls

[HelpingKid]

Hi All,

I am having a weird issue. Some of my outbound calls are getting super long delay and no issue with incoming calls. Like Yesterday i had 50 calls running and all of sudden 2 guys complain about long delay when they place an outbound call.

Call Flow

CUCM --> SIPtrunk --> CUBE --> Siptrunk --> Verizon (ISP)

I have attached logs files here and let me know what cause that super long delay.

Calling Number: 3134716751

Called number :918433047079

[Nithin Eluvathingal]

Are you using Single RP ?

Did you checked if there is alternative match on CUCM for 3134716751

[HelpingKid]

Yes, Single RP and no alternative match on CUCM.

Weird things is the call does come to CUBE and stay there for almost 2 mins with no next hop. Again, it happens randomly the same guy dial the number again and it works fine on 3rd attempt.

Not sure if that helps.

[Elliot Dierksen]

That sounds like you have dial peer matching issues in the CUBE.

[HelpingKid]

It matches the right outbound dial-peer and still the call stays on the CUBE.

[Maren Mahoney]

In your log file, you see the INVITE to 918433047079 enter the router (Line 2), the router selects incoming dial-peer 100 (Line 169) and dial-peer 200 as the outgoing dial-peer (Line 200). The TRYING message is sent back to 172.16.200.22 at timestamp 13:07:33.859 (Line 313). The next time we see 18433047079 referenced is the CUBE receiving a CANCEL from 172.16.200.22 at timestamp 13:10:33.504 (Line 99246) which is exactly 3 minutes later.

Later on you try the call again and it is successful. The inbound invite to 918433047079 (Line 277446), and again inbound dial-peer 100 is selected (Line 277613). But this time the outgoing dial-peer is 201 (Line 277644).

So the question is why the call is sometimes being routed out (unsuccessfully) vial dial-peer 200 and sometimes routed out (successfully) via dial-peer 201. Or, if the two dial-peers are load-balanced or are failovers, why the one is failing and the other is working. We'd have to see the CUBE config to figure this out.

Maren

[HelpingKid]

I can send you my router config. Please email me at majed.khan@LCEcorp.com and i will send it over.

[Maren Mahoney · Accepted solution]

Majed,

Interesting: So dial-peer 201 is the preferred dial-peer over 200, yet 200 was used first. Other than the preference, the significant difference between the two is the session target. Dial-peer 201 goes to dns:pce10001.xxxxxxxxxx.<domain>.com while dial-peer 200 goes to dns:pce10002.xxxxxxxxxx.<domain>.com

I think the problem is with the DNS query. In the first place, if the target of a session target in a dial-peer is not in the route table then the router will treat that dial-peer as shutdown. So the fact that it is not using dial-peer 201 first might be a DNS resolution issue, and the fact that it can’t signal out using the session target on dial-peer 200 at all might be a DNS resolution issue.

Suggestion: Try dns queries on your routers to the two targets to see what happens. Is there a lot of delay? Do they resolve at all?

Suggestion: Try changing both dial-peers to use IP addresses as the session targets temporarily to see if that resolves the issue. Or use a voice class server group for a dual-target dial-peer (and include the IPs). If calls work smoothly at that point, you know that DNS is the issue.

Maren