SIP Re-Invites

[hassanalirazi]

The call flow is

PSTN-GW -------SIP------->GW1-------SIP---->GW2-------SIP-Trunk------> CUCM.

When the call is being forwarded to an AA upon transfer the call gets dropped. I see a lot of re-invites taking place and the CCSIP message output shows a lot of retransmissions.

From what i can see a new invite message is sent before the first call is even established.......

The RTT delay between GW1 and GW2 is approximately 540 ms and when we enable MTP on the SIP trunks the call works through fine.

Is there anyway to stop these retransmissions? I have IOS 15.1(4) on GW1 i read a document that 15.2(1) has a feature the will consume mid-call invite but i want to test that as the last resort as these GWs are in a live environment.

I have tried changing the timers under sip-ua to 1000 but still no luck. Can someone please guide me ? Also the link is usually over utilized and QOS is in effect.

Hassan

[Ayodeji Okanlawon]

Hassan,

As simple as a transfer sounds it is one of the most complex things the gateway does. In a single transfer there are several re-invites so this is normal..This is how CUCM and the gateway does a transfer

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path

2. CUCM sends a Delayed offer to insert MOH or to resume Media stream

NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state

and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK

3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected

4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party

5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to MOH (in attempt to complete transfer)

6.Next CUCM sends an inactive SDP to indicate a break in media path between transfering party & transfered party to remove Xferring party from call

7. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends 200 OK with the required SDP to connect the call

As you can see there are lots of re-invites in that single transfer. The problem sometimes is that your ITSP doesnt interpret signalling properly during the break in media activity as indicated by the gateway and hence the call drops. When you insert an MTP, there is never a break in media path, so most times it works. The only way to stop re-invites during a transfer is to insert an MTP in the call flow as you have done.

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"