How can I send a 182 Queued SIP message from CCXML?

664 views Asked by At

I'm building a voice application that requires a long period of ringing while my application attempts to setup an outbound call. During this time, the call must remain unanswered.

I'm using a SIP based Genesys GVP 8.1 IVR connected to a media gateway.

The problem I have is because the call is unanswered, it times out after 30 seconds. I need to send some kind of keep-alive message to the media gateway to say that the call is still ongoing.

I've tried using this:

<send target="inConnectionID" targettype="'x-connection'" data="'connection.progressing'"/>

which will generate a 180 Ringing... but I've already sent a 180 Ringing message, and I think the SIP Server doesn't pass this on down the network because it's already processed a 180 message.

Ideally, I want to try sending a 182 Queued message, but I can't find anything in the CCXML or extended GVP CCXML documentation to say how to do this.

My Wireshark SIP trace looks like this:

Wireshark

You can see the second 180 Ringing at 24 seconds isn't being passed up to the media gateway.

How can I get GVP/CCXML to send a 182 Queued SIP message?

2

There are 2 answers

0
jesup On BEST ANSWER

The server should forward your 180, though it doesn't have to - but it should since the first 180 could be lost between it and the media server (though the server would re-send the INVITE probably).

However, as sipwiz indicates, the likely issue is the media server's configured max timeout to accept a call. 182 is unlikely to help (though without understanding the media server it's hard to be definitive).

Also, you should re-transmit the 180 (and the sip server should pass it through) every circa 1 min to avoid the possible 3-minute timeout allowed by the spec. Some SIP stacks like eXosip default to timing out an INVITE if 3 min go by with no 1xx response.

0
siphappens On

I agree that the media gateway should not cancel at 34.7. I also think the SIP Server should send a 100 trying back on leg1 before it sends the outbound invite for leg2. This will stop any retransmissions coming from leg1 UAC and prevent any failover if media gateway is using a SRV rollover algorithm.