CUBE - Media issue with TX9000

[Paulo Souza]

Hi Folks,

I am trying to setup a new telepresence environment and I am using CUBE to integrate this new environment to an existent telepresence infrastructure. However, I am facing some issues related to CUBE and TX9000 media negotiation.

I have this setup:

TX9000 >> CUCM >> CUBE_1 >> Firewall >> CUBE_2 >> CUCM >> CTS 3000

These are the versions that I have:

TX9000: TX6.1.0

CUCM: Both running 8.6.2 SU3

CTS 3000: 1.10.2

CUBE_1: 15.2(4)M2

CUBE_2: 15.1(4)M5

The CUBE's are using address hiding. The issue is, I can stablish the call normally between TX and CTS endpoints, however, there is no audio, only multiscreen video. Both sides cannot hear the other. Checking the media negotiation, I do confirm that the audio codec was negotiated normally, the codec used was AAC. I also confirm that it is not a firewall problem, because using the command "sh voip rtp connection", I can see the RTP for audio and video crossing both CUBEs normally, the firewall is not blocking the connection and it is not using any ALG/inspection feature. I also see both endpoints sending the audio, but not receiving it.

From the "debug ccsip error" command I have taken the following output?

Nov 12 18:27:37.959: //7844/B04B69800000/SIP/Error/sipSPIProcessRtpSessions: Active streams(4) exceeded the max number of streams allowed(3)

Nov 12 18:27:37.959: //7844/B04B69800000/SIP/Error/sipSPIDeleteExtraStreams: deleting the stream 4

Nov 12 18:27:37.959: //7843/B04B69800000/SIP/Error/sipSPISetStreamInfo: Main stream is NULL

Nov 12 18:27:37.959: //7844/B04B69800000/SIP/Error/sipSPI_ipip_GetOutboundPthruSdp: Invalid ccb/sdp information

Nov 12 18:27:37.963: //7843/B04B69800000/SIP/Error/sipSPIProcessRtpSessions: Active streams(4) exceeded the max number of streams allowed(3)

Nov 12 18:27:37.963: //7843/B04B69800000/SIP/Error/sipSPIDeleteExtraStreams: deleting the stream 4

Well, it seems CUBE is blocking the audio streaming (stream 4) because it does not allow more than 3 media streamings. This is the only error I get from the outputs of the debugs, the media negotiation in SIP signalling works fine.

Can anybody clarify me about that strange error? What do I have to do to make this scenario work through CUBE?

This is the main configuration applied to CUBE:

voice service voip

rtp-ssrc multiplex

address-hiding

mode border-element

allow-connections sip to sip

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

sip

  session transport tcp

  rel1xx disable

  header-passing

  error-passthru

  midcall-signaling passthru

  pass-thru content sdp

Regards

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".        

[Nick Halbert-Lillyman]

Hi Paulo,

Do you know if the CUBE works for CTS to CTS calls?  It would be good to see if this issue is specific to TX9000s or if it affects mult-screen endpoints in general.

I did a fair bit of work in a similar scenario with CUBE a while ago - I'll see if I can dig out some of the connfig once I get to work (we had to do some extra config on top of what you had). 

We didn't have your exact problem, but we did have a heap of issues with multi-screen calls that we eventually managaged to get fixed.

Even if you don't have a CTS-3XXX on the same side as your TX9000 to test with, you still might be able to "dial via" CUBE between 2 x CTS-3XXX on the same side.

[Paulo Souza]

Hi Nick,

Thank you very much for your reply.

I guess I can try to replicate the issue using two CTS endpoints. Meanwhile, would you be able to share with me the configuration of your CUBE? I would like to see another configuration just to make sure that I am not missing any point.

Thanks

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[Nick Halbert-Lillyman]

Hi Paulo,

The issue we had stemmed from the fact that CUBE natively supported only old-style Cisco SIP-MUX, rather than TIP.  I'm not sure the TX9000 works with SIP-MUX.

We were able to get around this using the following:

voice-class sip-profiles 1

request INVITE peer-header sip Contact copy "(;x-cisco-tip)"

request INVITE sip-header Contact modify "$" "\u01"

voice-class sip-copylist 1

sip-header Contact

!

voice service voip

sip

sip-profiles 1

sip-copylist 1

This copied the "x-cisco-tip" header.

Note that I believe we may have also had to turn off some of the SIP-MUX specific commands, but I'm still trying to find the rest of the config (it's been a couple of years!).

[Nick Halbert-Lillyman]

Here's the full relevant config:

EDIT: pasting problems.

Here are the relevant pieces of config:

ip host yourdomain.com 1.1.1.1  ! to solve CUBE bug relating to contact header

!

voice service voip

no ip address trusted authenticate

address-hiding

mode border-element

allow-connections sip to sip

fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none

sip

  session transport tcp

  rel1xx disable

  min-se 500 session-expires 500

  midcall-signaling passthru

  pass-thru content sdp

  sip-profiles 1

  copy-list 1

  reset timer expires 183

!

voice class sip-profiles 1

request INVITE peer-header sip Contact copy "(;x-cisco-tip)" u01

request INVITE sip-header Contact modify "$" "\u01"

!

voice class sip-copylist 1

sip-header Contact

!

!

!

dial-peer voice 141 voip

snmp enable peer-trap poor-qov

preference 3

destination-pattern 14.T

rtp payload-type cisco-codec-fax-ack 111

rtp payload-type cisco-codec-fax-ind 110

rtp payload-type cisco-codec-aacld 96

rtp payload-type cisco-codec-video-h264 112

session protocol sipv2

session target ipv4:

incoming called-number 14.....$

voice-class sip options-keepalive

codec transparent

ip qos dscp cs4 video rsvp-none

no vad

!

dial-peer voice 101 voip

snmp enable peer-trap poor-qov

preference 1

destination-pattern 1[0-3,5-9]T

rtp payload-type cisco-codec-fax-ack 111

rtp payload-type cisco-codec-fax-ind 110

rtp payload-type cisco-codec-aacld 96

rtp payload-type cisco-codec-video-h264 112

session protocol sipv2

session target ipv4:

incoming called-number 1[0-3,5-9]T

voice-class sip options-keepalive

codec transparent

ip qos dscp cs4 video rsvp-none

no vad

!

EDIT: I also notice that our config didn't have rtp-ssrc multiplex.  Again I stress that this was a long time ago by I vaguely remember needing that command when using SIP-MUX but needing to remove it for TIP.

[Paulo Souza]

Hi Nick,

Thanks for sharing your configuration.

Well, my configuration looks like yours, there are few differences. Basicly I dont have that configuration applied:

voice service voip

sip

  sip-profiles 1

  copy-list 1

  reset timer expires 183

!

voice class sip-profiles 1

request INVITE peer-header sip Contact copy "(;x-cisco-tip)" u01

request INVITE sip-header Contact modify "$" "\u01"

!

voice class sip-copylist 1

sip-header Contact

!

But even with that custom SIP configuration, the call does not work well, I still have only video, no audio.

Well, as far as I can see, it seems the CUBE is not understand TIP negotiation. I have a TAC case open, Let's see what TAC suggests.

Thanks again.

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".

[Nick Halbert-Lillyman]

I also believe that the numbers at the end of the rtp-payload configurations in my dial-peers are slightly different from the CUBE documentation (as well as the rtp-ssrc multiplex I mentioned before).  Check your dial peers to see if they are the same as what I have in my configuration.

[Paulo Souza]

Hi Nick,

The dial-peers also looked the same, inclusing the multiplex command.

Well, after many hours performing troubleshooting with TAC support, TAC has discovered that we were hiting the bug CSCub93496 that may occur when we have SDP Passthru mode enabled on CUBE.

In fact, the audio was being received from an endpoint to another, but the traffic was ignored by the endpoint because the packets forwarded by CUBE had the SSRC set to 0x0, as described in the bug description. Therefore, we had no audio on the call, only video.

The workaround was to apply the following commands to the dial-peers:

rtp payload-type cisco-codec-fax-ack 127

rtp payload-type cisco-codec-fax-ind 110

This bug has already been fixed in latest IOS versions, therefore I recommend to upgrade the IOS instead of applying the workaround, if possible. But the workaround is an option as well.

Well, my scenario is not working yet, because I am also facing some firewall and network issues, but I guess at least the CUBE configuration is fixed and ready.

Thanks again.

Paulo Souza

Was my response helpful? Please rate useful replies and remember to mark any solved questions as "answered".