No Audio ITSP with CUBE and UCCX

[Brendan Ord]

Hi all,

Firstly, thank you for helping me out with this one.

I am attempting to bring up a SIP VOIP service via a 2811 "CUBE".  The topology is;

VSP ----{ INTERNET }---- CUBE ----{ SIP TRUNK }---- UCM 11 ---- UCCX 11

So far, everything has worked well.  I can make outbound SIP calls successfully from ephones registered to UCM, and I can send an inbound SIP call to the same UCM ephone - audio works both ways, calls work etc.  This part between CUBE -- UCM is working.

However, when an inbound call gets sent to a UCCX CSQ script application instead of directly to an extension there is no audio in either direction.  No MOH while ringing agents, and once an agent answers no audio in either direction.  Add to this, if I ring a UCCX IVR script application I can hear the IVR Prompts, make a selection - however, once that selection is made and I should hear the MOH track the audio disappears, same when an agents answers.

It seems that whenever MOH is involved, it breaks the media altogether.  I have tried setting the UCM Trunk to a Unicast and Multicast MRGL, and tried with and without MTP Required checked.

I'm sure I'm missing something simple.  This is the first time I've attempted a SIP connection via a CUBE with CCX in the mix (previously, was only a requirement for outbound).  I've been studying a debug ccsip messages output from the CUBE, and I cannot pick up any problem in that but maybe I am looking at the wrong stuff; SDP seems to indicate the correct IP's for endpoints to establish RTP with (ephone and UCM).  There are a lot of invites/re-invites but I assume that's due to swapping media over to MOH etc..

Let me know which parts of config you would like to see as well.  The CUBE config is simple - sip-ua to register to VSP and some dial-peers.  I haven't mucked around with bind control or bind media commands under voice service voip sip.

Thanks in advance,

[Brendan Ord]

To add a further, quick test;

I sent a call directly into UCM to my ephone.  I could hear ringing, when I picked up I had audio in both directions.

When I put the call on hold, I heard no MOH track.  When I resumed the call, the audio was broken.

Problem seems to be narrowed down to RE-INVITEs in order to play MOH.  And, doesn't seem to recover once the call is INVITEd back into the conversation (resumed).

Is this something up with using MTP on this trunk, and configuring on the CUBE as well?

Also - we are using PCM uLaw everywhere, no transcoding going on.  Ephones are uLaw, SIP trunk is uLaw and the SIP connection to VSP comes up with uLaw.

[Brendan Ord]

Still trying to work this one out, studying another ccsip messages debug output and trying to learn more about signalling when a call is put on hold.  This is what's happening in my output when a call is put on hold;

1. CUCM sends reINVITE with a=inactive in SDP (to break media stream)

2. CUBE replies with 100 Trying and 200 OK containing SDP including a=inactive

3. CUCM sends back ACK

4. CUCM sends another reINVITE, no SDP (to bring in MOH)

5. CUBE replies with 100 Trying and 200 OK that includes SDP, however without a direction a= value (no a=sendrecv, no a=sendonly etc)

6. CUCM replies with ACK, containing SDP also without a direction however now contains a=X-cisco-media:umoh (indicating unicast MOH)

So, is it possible that because there is no direction attribute that the call leg is staying at inactive due to that being the last value when the first REINVITE happens to interrupt the media (before the REINVITE to bridge into MOH)?

I checked under System -> Service Parameters and 'Enable Duplex Streaming' is set to True already.  I do not have MTP Required set on the UCM SIP Trunk to CUBE.  I am also unable to set

voice service voip

  sip

    midcall-signalling passthru

as this command doesn't seem supported on the router I'm using as a CUBE (running IOS spservicesk9-mz.124-25).

[Dennis Mink]

With this sort of thing you might also want to check the c=<ip address> in the SDP, which is the IP address to which one end of the RTP stream should be terminate and of course typically is the IP address of the agents phone.

Please rate if helpful. 

[Brendan Ord]

Thanks, Dennis.

Yes, this is the first thing I check - the endpoint IP as well as port that RTP will get setup on.  All looks good to me - media does get setup with the ephone when I expect it should.

[Brendan Ord]

Could this be an IOS issue - we are running spservices.  These have been fine in the past for terminating our physical E1 and tunneling the signalling via MGCP.

[KNast]

Hello, do you have some idea? I have problem like your problem.

[Dennis Mink]

OK so do you see the ip address of uccx as the termination point or a phone and can you ping both ways?