IP Phone takes too long to send calls to SIP gateway

[HeribertoVV]

Hello,

I have these IPPhone models: 7821, 8841, 8851. I make Calls with this logic:

SIP IP phone ---- one route pattern exact match ---- SIP Trunk --- SIP Gateway --- one dial-peer exact match --- E1 (PSTN).

When I make calls I observe that it takes too long to send the call to the gateway. The route pattern match correctly, I write the FAC and after that it takes aproximately 7 seconds to give me the calling sound. With 7821 IPPhone in these 7 seconds I see the behavior on the attached photo.

Also, I have another gateway (as H323 in CUCM) and this doesn't show this issue. Actually, It routes the call pretty fast.

Attached are my gateway config and my SIP Trunk config.

[Chris Deren]

Are you pressing # after the FAC code?

[HeribertoVV]

Yes, I am.

After I press # I see logs in the gateway, what makes me suppose that the issue is in the it. I send captured logs.

[Chris Deren]

From the logs it appears the call is matching outbound dialpeer 1003 right away and call setup is sent to FRISA trunk group, and that is when the delay occurs.  Any reason what you assign the trunk group without priority at the controller level, this makes all ports load balance the calls instead of preferring one over another?  Can you provide "debug vpm signal" along with the "debug voice ccapi inout" and "debug ccsip messages" debugs you have on?

Another thing to consider is to enable Early Offer via the SIP profile applied to the SIP trunk to speed things up and use CUCM to control codec, etc rather than the GW.

[HeribertoVV]

Thank you, Chris. These are the logs I captured.

What option in the SIP profile enables Early Offer? I see 

[Chris Deren]

CAS circuits are not my specialty as I only see them occasionally these days, but it appears there is a lot of:

157480: Dec 29 20:10:42.555: r2_reg_generate_digits(0/1/0:1(6)): Tx digit '#'
157481: Dec 29 20:10:42.647: htsp_digit_ready(0/1/0:1(6)): Rx digit='#'

which adds to quite a delay, so i don't think the issue has to do with CUCM or SIP, but rather with the E1-CAS circuit. I do recall seeing similar dealy many years ago, but don't recall the solution. You may want to do some googling on E1/T1-CAS delay issues.

For reference for EO support "Early Offer support for voice and video calls" set to "Best Effort (no MTP inserted)".

[HeribertoVV]

Thank you, Chris. These are the logs I captured.