Two SIP INVITES same call-id

[Grant Bagdasarian]

Hello,

I'm having a problem where both the incoming SIP INVITE and the outgoing(for transfer) INVITE are having the same Call-ID in their SIP message.

This is causing the incoming call to be dropped when our system(VXML application) is trying to transfer the call.

Does anyone know how to fix this?

[Daniele Giordano]

I suppose that the call passes through a cisco gateway.

What is this gateway?

Can you enable the ip to ip modality? In this way the gateway terminates a call leg and generates a new call leg.

The command to enable this feature is:

voice service voip

  allow-connection sip to sip

Regards.

[Grant Bagdasarian]

I'm sorry, the incoming SIP INVITE and the outgoing both have a different Call-ID, but for some reason our gateway does a new INVITE back to the caller after the INVITE to the destination. This INVITE does have the same Call-ID as the first incoming SIP INVITE. According to our SIP provider this is not ok and every INVITE should have a different Call-ID.

We have a Cisco 3825 ISR with IOS 12.4(15)T9 and CME 4.1.

A call comes into our gateway and then a Vxml application is executed which plays an audiofile and then transfers(bridge) to another destination.

The allow-connections sip to sip is enabled.

[Daniele Giordano]

In theory a transferred call can have same CALL-ID but a different BRANCH.

Can you add the output of "debug ccsip all" command?

Regards.

[Grant Bagdasarian]

I;ve attached the output to the first post.

[Daniele Giordano]

Sorry, but the call flow is not clear.

Can you describe who is the caller, the called, the transferred number.

I see an incoming INVITE and two outgoing INVITEs with same CALL-ID. Is the call forked? Outgoing INVITEs have different BRANCH and this should discriminate the call.

This INVITE is generated by your vxml?

Regards.

[Grant Bagdasarian]

Caller: 31765701000

Called: 31103401001

Transferred: 0031765701003

dial-peer voice 2000 voip

description **Incomming Call to SIP Trunk**

service voiceforwarding

voice-class codec 100

voice-class sip dtmf-relay force rtp-nte

session protocol sipv2

session target sip-server

incoming called-number 31103401001

dtmf-relay rtp-nte

no vad

When the caller calls us(called) then a VXML application is exectuted which plays an audiofile and then transfers to the transferred phonenumber. What happens is as soon as the transferred party starts ringing the leg between caller and called is dropped, but the transferred parties phone still rings.

The weird thing is, this only happens when an audio file is played and then transferred to a landline phonenumber. When I omit the audio file and transfer to a landline phonenumber, it works. Also when playing an audio file and forwarding to a cellphone it also works for most operators in Holland, except for Vodafone(same issue). But according to our SIP provider these three scenarios should all not work because it's not supported by their platform.

I don't know if the call is forked. How can I verify this?

[Daniele Giordano]

Can you add the vxml script?

[Grant Bagdasarian]

Which part of the VXML are you interested in? I'm not allowed to make our source code public.

[Daniele Giordano]

Can you modify your script to play the announcement in early media?

Now the script answers the call and send a 200 OK with SDP.

After receiving the ACK response, the call is connected.

In early media the sip user agent sends a 183 with SDP.

After the ACK you can play an announcement without connection.

[Grant Bagdasarian]

I don't know how to modify the VXML so the media file is played as early media. It's a pure VXML file and I didn't come accross any early media topics in the programming guide.

When the caller calls us they do hear the audio file played to them, but as soon as the transfer starts and the destination rings the call between the caller and us is terminated.

I  doubt it's a VXML problem, because I've created a new VXML application with only a prompt tag which plays an audio file and then a transfer to another destination. The end result was the same.