Problem with making call from SIP Server to outside via CUBE

[nonny]

Problem I have is testing an inbound call that comes in via a CUBE, hits a dial plan then routes back out via the CUBE through a Trunk DN to an external number.

I get the INVITE for the first inbound call fine, but things turn weird for me when it gets to the point of forwarding the call back out.

I see the INVITE going out to the CUBE for the outbound leg which responds with a 100 Trying.  The CUBE then sends an INVITE back to SIP Server for the original inbound DNIS (not sure if that's expected).

This is then followed up by SIP Server sending the CUBE two 100 Trying messages and then promptly by a CANCEL request from the CUBE.  What's odd is our Cisco guy is telling me he sees the CANCEL request coming FROM SIP Server saying that SIP Server must have expired SIP Timers waiting for a response.  Seeing as the CUBE responds with a 100 Trying initially I'm not sure if that's right, but I've increased the sip-invite-timeout option and various 100rel options with no change.

Following is the call extract from the SIP Server log:

[url=https://www.dropbox.com/s/0ra1d8s97udi4a9/Cancel%20Problem.txt?dl=0]https://www.dropbox.com/s/0ra1d8s97udi4a9/Cancel%20Problem.txt?dl=0[/url]

[genesysguru]

Have you got a wireshark trace? CANCEL is received from 10.56.250.202 for call-id C95B1AAB-230011E5-8F38B1B6-C417AAF2@10.56.250.202 so timeouts on that side would seem to be the root cause.

22:29:44.842: SIPTR: Received [0,UDP] 1187 bytes from 10.56.250.202:49656 <<<<<
INVITE sip:4841138@10.94.128.60:5060 SIP/2.0
Via: SIP/2.0/UDP 10.56.250.202:5060;branch=z9hG4bK28DBDE7B

22:29:45.716: SIPTR: Received [0,UDP] 405 bytes from 10.56.250.202:49656 <<<<<
CANCEL sip:4841138@10.94.128.60:5060 SIP/2.0
Via: SIP/2.0/UDP 10.56.250.202:5060;branch=z9hG4bK28DBDE7B
From: "anonymous" <sip:anonymous@10.56.250.202>;tag=108DB7D8-700
To: <sip:4841138@10.94.128.60>
Date: Mon, 06 Jul 2015 10:29:59 GMT
Call-ID: C95B1AAB-230011E5-8F38B1B6-C417AAF2@10.56.250.202

[nonny]

Yes that was my understanding from the logs as well (CUBE timing out sending CANCEL).

Here's what our Cisco/SIP Trunk guy has come back with:
[i][b]
For inbound calls from the provider into us, provider need to see a 18X message within 1 second after they send their initial Invite. If they don't then they cancel the call and try the other trunk. This is their' Intercluster trunk failover' feature.
If an inbound call is forwarded straight back out to the provider (Call forward all),  the 183 progress message that is sent out to them on the inbound call leg, originates from the outbound call leg. So if there is a +1 sec delay receiving the 183 from the provider (which there is for mobile calls) then the inbound call will time out. The fix for this is for the CPE (CUCM or GVP) to send a 181 (call is being forwarded) message to ensure that the call is not timer out. [/b][/i]

So that makes sense.  The question is, what configuration needs to (or can be) done within the Genesys environment to make sure the 181 is being sent?  The only obvious 181 type config option I came across seems to relate more to voicemail.

[nonny]

Any ideas out there?

[genesysguru]

Might be worth reviewing the following SIPS options:

sip-enable-100rel
sip-early-dialog-mode
sip-server-intertrunk

[nonny]

Thanks, those options look interesting now I see them from a different angle.

Will post back the outcome.