cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2318
Views
0
Helpful
4
Replies

CVP sends reinvite through cube to carrier

alex.dersch
Level 4
Level 4

Hello Members,

i have a question regarding CVP / Cube with SIP. I have following architecture. Call is coming over a SIP trunk from the carrier and hits the CUBE where the call gets forwarded to the CVP VXML gateway. The gateway send the call to the CVP callserver which sends a route request to IPCC. Route response is a play media which is streamed back to the caller. When call then is sent to the agent on a CUCM the call gets disconnect.

It seems that the CVP sends a re-invite to the VXML gateway which forwards the re-invite to the CUBE. The CUBE send it then to the carrier. The carrier is not responding to this re-invite which causes the call manager to send a BYE and the call disconnects.

My question is

1. why does the CVP sends the re-invite back to the carrier, the agent is just an extension which is never know in the PSTN? For my understanding the call terminates at the VXML gateway and when the call is transferred to the agent the call legs are established on the VXML gateway.

2. can the cube be configured not to send the re-invite back to the carrier instead sending the ACK in behalf of the carrier.

thanks

alex

1 Accepted Solution

Accepted Solutions

Kris Lambrechts
Level 1
Level 1

Hey Alex,

When you go to an agent 2 things need to happen (well 3 actually) :

  • CVP starts a new dialog towards the agent's extension, where that is depends on your CVP Static Routes for the agent extension or CUPS/CUSP configuration if you're using a SIP Proxy;
  • We need to send a re-INVITE to the caller at the ingress gateway (in your case the CUBE and by extension the SIP trunk ) to re-negotiate codecs.

I'm saying 3 as the re-INVITE actually happens twice : first we re-INVITE the caller and have him talk to the ringback dial-peer. As soon as the agent actually answers we re-INVITE the caller again to establish media with the agent's phone. The VXML Gateway is not a part of this story. As soon as you hit an agent, the VXML Gateway leg disappears from the picture.

So have a closer look at the re-INVITE going out to the SIP trunk, it's probably just to re-negotiate media. If that's currently getting rejected you have two options :

  • The obvious option : get the SIP provider to accept re-INVITEs;
  • Use media flow-through on the CUBE, which will make it act like an MTP on CUCM, i.e. media goes through the CUBE and the re-INVITEs will 'stop' at the CUBE, there's no need to re-INVITE the SIP trunk when we change the endpoint from the VXML gateway to the ringtone dial-peer to the agent's phone.

    Cheers,

    Kris

    View solution in original post

    4 Replies 4

    geoff
    Level 10
    Level 10

    Can you post your CUBE config and your VXML gateway config?

    Regards,

    Geoff

    Hey Geoff,

    thanks for having a look at it. The cfg files are attached.

    regards

    alex

    Kris Lambrechts
    Level 1
    Level 1

    Hey Alex,

    When you go to an agent 2 things need to happen (well 3 actually) :

    • CVP starts a new dialog towards the agent's extension, where that is depends on your CVP Static Routes for the agent extension or CUPS/CUSP configuration if you're using a SIP Proxy;
    • We need to send a re-INVITE to the caller at the ingress gateway (in your case the CUBE and by extension the SIP trunk ) to re-negotiate codecs.

    I'm saying 3 as the re-INVITE actually happens twice : first we re-INVITE the caller and have him talk to the ringback dial-peer. As soon as the agent actually answers we re-INVITE the caller again to establish media with the agent's phone. The VXML Gateway is not a part of this story. As soon as you hit an agent, the VXML Gateway leg disappears from the picture.

    So have a closer look at the re-INVITE going out to the SIP trunk, it's probably just to re-negotiate media. If that's currently getting rejected you have two options :

    • The obvious option : get the SIP provider to accept re-INVITEs;
    • Use media flow-through on the CUBE, which will make it act like an MTP on CUCM, i.e. media goes through the CUBE and the re-INVITEs will 'stop' at the CUBE, there's no need to re-INVITE the SIP trunk when we change the endpoint from the VXML gateway to the ringtone dial-peer to the agent's phone.

      Cheers,

      Kris

      Hey Kris,

      hope you're doing well. We spoke to our carrier and he commited that he has to accept the reinvite. But it will take a while until he upgrade his platform. Meanwhile i changed the call flow. I send the call not to the CVP Callserver anymore, i send it now to a CUCM and he handle all the messages. It's working fine now, but i'll try media flow through option on my CUBE.

      regards

      alex from b+s