Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2305
Views
0
Helpful
4
Replies

CVP sends reinvite through cube to carrier

Go to solution
alex.dersch
Level 4
Level 4

‎02-15-2011 01:56 AM - edited ‎03-14-2019 07:22 AM

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

Labels:
0 Helpful
1 Accepted Solution

Accepted Solutions

Go to solution
Kris Lambrechts
Level 1
Level 1

‎02-22-2011 01:54 PM

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

    0 Helpful
    4 Replies 4

    Go to solution
    geoff
    Level 10
    Level 10

    ‎02-15-2011 09:23 PM

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

    Regards,

    Geoff

    0 Helpful

    Go to solution
    alex.dersch
    Level 4
    Level 4
    In response to geoff

    ‎02-16-2011 09:47 AM

    Hey Geoff,

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

    regards

    alex

    81583-vxml_gw.txt.zip
    0 Helpful

    Go to solution
    Kris Lambrechts
    Level 1
    Level 1

    ‎02-22-2011 01:54 PM

    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

      0 Helpful

      Go to solution
      alex.dersch
      Level 4
      Level 4
      In response to Kris Lambrechts

      ‎02-22-2011 02:34 PM

      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

      0 Helpful
      Customers Also Viewed These Support Documents