cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
20457
Views
25
Helpful
13
Replies

CUBE: SIP-to-SIP "pass-thru content sdp" & the DTMF relay implication

I just want to share my findings, in case it is of any benefit to the community.

I find that when the command "pass-thru content sdp" is used,   During the call set up process, while the CUBE doesn't at all inspect SDP portion of the SIP request, it does mess around with the DTMF-relay preference.   This will cause the problem especially when the callee is a CTI ports.  (such as UCCX application, CUC, etc)

It is also simple to test out this behavior.   And, use only one type of dtmf-relay at a time.   You will find that with "dtmf-relay sip-kpml" or "dtmf-relay sip-notify", for incoming calls, CUBE will present it as part of INVITE to CUCM, CUCM will ACK it, but then upon receiving the ACK, CUBE will filter them out before presenting the ACK to the caller.   (Note: Both sip-kpml and sip-notify are not present as part of the SDP, but present as part of the SIP header, where CUBE is not passing through without any manipulation.)    As a result, the CUCM will user sip-kpml/sip-notify and the caller will think that the call doesn't support any dtmf-relay at all.

The reason I used one dtmf-relay type at a time for my testing is so that I can observe the full interaction of the configuration with regard to each dtmf-relay type.

voice service voip

sip

  bind control source-interface GigabitEthernet0/0

  bind media source-interface GigabitEthernet0/0

  session transport tcp

  rel1xx disable

  header-passing

  error-passthru

  midcall-signaling passthru

  pass-thru content sdp

dial-peer voice 6000 voip

destination-pattern .T

session protocol sipv2

session target ipv4:192.168.1.100

session transport tcp

voice-class codec 1

dtmf-relay rtp-nte

ip qos dscp cs3 signaling

no vad

!

dial-peer voice 1000 voip

session protocol sipv2

session transport tcp

incoming called-number .T

voice-class codec 1

dtmf-relay rtp-nte

ip qos dscp cs3 signaling

no vad

!

Most source on the Internet will say it is best to best use "rtp-nte" without pointing out the rational behind it. 

So, in essence, the combination between "pass-thru content sdp" and "dtmf-relay sip-notify" or "dtmf-relay sip-kpml" will cause an undesirable behavior esp. with regard to CTI-based application.

voice service voip

sip

  pass-thru content sdp

dial-peer voice 6000 voip

...

dtmf-relay sip-notify   <=== not going to work, CUBE break the negotiation of dtmf-relay

...

...

or

dial-peer voice 6000 voip

...

dtmf-relay sip-kpml   <=== not going to work, CUBE break the negotiation of dtmf-relay

...

...

or

dial-peer voice 6000 voip

...

dtmf-relay sip-kpml rtp-nte  <-- both won't work

dtmf-relay sip-notify rtp-nte

...

...

Only when you "rtp-nte" is forced that dtmf-relay will work correctly.

Note: show sip-ua calls, "Negotiated Dtmf-relay" will always be "inband-voice" when "pass-thru content sdp" is used.

     Negotiated Codec         : pass-through

     Negotiated Dtmf-relay    : inband-voice  <--- CUBE just forward all RTP traffic from one call leg to another call leg, don't assume that this both side has successfully negotiated for "rtp-nte"

When the "pass-thru content sdp" is not being used, you can expect:

     Negotiated Codec         : g711ulaw (160 bytes)

     Negotiated Dtmf-relay    : sip-notify

or

     Negotiated Codec         : g711ulaw (160 bytes)

     Negotiated Dtmf-relay    : sip-kpml

or

     Negotiated Codec         : g711ulaw (160 bytes)

     Negotiated Dtmf-relay    : rtp-nte

13 Replies 13

Ayodeji Okanlawon
VIP Alumni
VIP Alumni

Hi, thanks for sharing this...I looked at the documentation for pass thru dsp and it mentioned that there are limitations with DTMF inter working...perhaps this is the reason for this behaviour

http://www.cisco.com/en/US/docs/ios/voice/cube/configuration/guide/vb_9320.html

Please rate all useful posts

Yes, that's likely it.   I have spent a few days working on a simple case where caller call in to a UCCX IVR and the DTMF doesn't seem to work, and have learnt a fair bit about CUBE so I would put it out here in case it helps other.  (As well as perhaps having people with the right equipment try to re-produce the outcome I've had.)

This case in particular is about incoming call to our CUCM via CUBE.   This involves Early Offer SIP INVITE. (i.e. INVITE + SDP).     

Just to elaborate a bit more on when both OOB & in-band DTMF relay is configured on dial-peers.    CUCM will receive INVITE+SDP that supports both OOB (either sip-kpml or sip-notify) && in-band (rtp-nte), unless MTP required is checked, the CUCM will check the callee device's capability which in our case happens to be a CTI port which supports only OOB dtmf (either SCCP dtmf or sip-kpml), so it is natural that CUCM choses to ACK+SDP on the OOB dtmf to avoid having to create an MTP for this.    But, somehow, CUBE filter the OOB dtmf out from the ACK+SDP reply before sending to the caller.   The caller then send DTMF in-band and the DTMF wouldn't be converted into OOB for the CTI to consume as the MTP is not activated.    (For the typical IP Phone or IVR that supports DTMF in-band, this will continue to work despite the fact that caller & callee has never quite managed to negotiate for DTMF).

The solution is simple, when "pass-thru content sdp" is used, ensure that only "rtp-nte" is listed as dtmf-relay method.

Out of curiosity, I played around with removing "pass-thru content sdp" a bit too.  I will document my (more detail) findings concerning that a bit later.   In short, when "pass-thru content sdp" is not configured.   I need to put in  "asymmetric payload [dtmf | dynamic-codecs | full]" to allow video calls to work correctly -- otherwise only the callee gets to see the video. (I.e. caller is a Jabber client and callee is CIsco 9971).   All DTMF works (sip-kpml, sip-notify, rtp-nte), show sip-ua calls reported correct dtmf-negotiation result).     

All is well and good.   The only catch is that when the callee (on my end) put the call on hold.   If the caller is the Jabber client, the call will fail.   I have the call trace for that, but in short, there seems to be a bug on CUBE that can't handle the  200 OK reply coming from the caller side for the MoH RE-INVITE Delayed Offer sending out from my side.   Upon receives that 200 OK reply, CUBE doesn't even send out ACK.     That's happen only when the caller is a Jabber client, if the caller is a CIsco IP Phone with no video, it is fine, the HOLD is successful.  (This assumes "midcall-signaling passthru" is used, i.e. CUBE doesn't handle the mid-call.)

When "midcall-signaling passthru media-change" or "no midcall-signaling passthru" is configured (i.e. CUBE consumes the RE-INVITE for call hold without passing it right back to the caller), it is well and good with Cisco phone (audio only) because it doesn't work well with Video-based client, in our case Jabber client on the other side for both Call Hold or Call Transfer to the Video phone 9971.  

So, at the end, we settled for "pass-thru content sdp".+ rtp-nte only.   It can endure our test cases so far.   Our CUBE is to support all voice, video (Jabber & 9971) as well as telepresence call.   (BTW, codec transparent is required on dial-peer too.   We don't get to see the negotiated codec via "show sip-ua calls" as it will always show "pass-through" as a result of "pass-thru content sdp" --- this is true even when we tried to change codec transparent to codec g711ulaw just to see the outcome).  Voice class codec will work too as far as "codec transparent" is listed first.

voice class codec 1

codec preference 1 transparent

codec preference 2 g711ulaw

etc.

The CUBE I tested is running on IOS 15.2.2T1, Our CUCM is 8.6.x

I am indebted to our partner organization who I shall keep their name protected, but I'd like to acknowledge their patience and generous assistance to help making countless amount of test calls throughout the period to satisfy my curiosity to try to understand the CUBE behavior a bit more..

Hi,Somopholboonjing

Ver helpful post from you,i have the same problem and i think you post is the answer to my question.

Dtmf digits through CUBE to uccx are not recognized and i have MTP checked on the sip trunk.

If i uncheck mtp on the sip trunk,dtmf works but i have one way voice.The pstn caller never hears the audio.

I tried to use this command

pass-thru content sdp,but it's not supported in my ios.

I am using :

Cisco IOS Software, 2801 Software (C2801-ADVENTERPRISEK9_IVS-M), Version 12.4(24)T3, RELEASE SOFTWARE (fc2)

Do you have any idea how to solve this issue.

here is my cube config:

voice service voip

address-hiding

dtmf-interworking rtp-nte

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

supplementary-service h450.12

redirect ip2ip

fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback pass-through g711ulaw

h323

emptycapability

sip

bind control source-interface FastEthernet0/1

bind media source-interface FastEthernet0/1

header-passing

registrar server

early-offer forced

midcall-signaling passthru

Thanks Man.Really helpful post.

Hi Ahmed,

I'm glad you find the post useful.   I may not be able to tell you exactly what is wrong in your case, but I'm willing to help.   So, forgive me in advance if this would requires a bit of a patience while we try to nail it.

> pass-thru content sdp,but it's not supported in my ios.

> If i uncheck mtp on the sip trunk,dtmf works but i have one way voice.

If we deal strictly with audio call, then we should be fine without "pass-through content sdp".   If I have to choose between always checked the MTP on the SIP trunk or leave it to CUCM to make decision, I am inclined to leave it upto CUCM because MTP won't need to be created if it is necessary and it is more efficient that way.   

But, before we focus on the one-way auto problem.     Ummm...just to be sure, configured the SIP Trunk's profile to create "MTP when needed".   Once this is done, and if you can afford to, try to force the dial-peer on both sides of the call legs to use "rtp-nte", then the MTP would be activated automatically by CUCM. 

Be sure to check that the SIP Trunk's MRGL contain the CUCM-based Software MTP or if it is an IOS-based MTP don't forget to include "codec pass-through" keyword, this seems to be necessary when I tested it out, I found that unless "codec pass-through" is part of the IOS-based MTP config, it is not selected by CUCM (I put it in its own MRG and place it in a separated MRGL and rank it first in the MRGL list), CUCM seems to prefer the CUCM-based MTP instead.

At this point, DTMF between the UCCX CTI ports and the allocated MTP should be out-of-band (I am not sure which one, but it can only be SCCP DTMF or SIP-KPML) and because we have forced the dial-peer to use "rtp-nte", the DTMF between the MTP and the CUBE will be rtp-nte.    ("show sip-ua calls" should also show that the negotiated DTMF as "rtp-nte".)

> Dtmf digits through CUBE to uccx are not recognized and i have MTP checked on the sip trunk.

I know that we haven't really addressed the mystery why when you seems to have DTMF problem even when you have checked that the MTP on the SIP trunk.   It should work.  

I am aware however of the fact that the default settings on CUCM allows the call to be established successfully even when you check that MTP is to be allocated on the SIP Trunk but the MTP resource is not available somehow.     So, my best guess is that somehow your SIP Trunk do not actually have access to the MTP resource.  (Perhaps, incorrect or no MRGL on SIP Trunk?)

Please see this article by William Bell for more detail - http://www.ucguerrilla.com/2012/12/ccie-v-i-shoulda-checked-that-tip-3-mtp.html

Hope you get some idea how to proceed from here.

Excellent Mr.Sompholboonjing

Great when i used rtp nte only.The dtmf worked and no one way voice.

GREAT.Thanks man so so much

Hi Ahmed,

Thanks for providing the outcome.  If you can live with forcing "rtp-nte" as the only dtmf-relay on the dial-peer, then that should be it.    In this case, CUCM will activate an MTP.   RTP will flow between your CUBE and the MTP.

Now, depending on your ITSP, I suspect that if your ITSP can only support "rtp-nte", then this probably is the best you can do.   

It is not the best option  because MTP will always need to be activated for call involving CTI ports.  (Calls with Cisco IP Phone won't involve MTP as most of  the phone model can support rtp-nte natively.)

If however, your ITSP supports either "sip-kpml" or "sip-notify" (or both) too, then you may want to experiment with changing your dial-peer to force each of them (one at a time).  

Now in this case, because CTI ports support only OOB DTMF-relay and your CUBE will force one of the OOB dtmf, MTP will not be allocated, but you should not experience DTMF-relay issue.  You may still face the one way audio. (Note: Because the call will be established with the CTI ports, there is no way to tell for sure that it is one way audio problem, it could well be two-way audio problem.)   Because MTP is not activated, the RTP will flow between your CUBE and the UCCX server.   And you may want to check whether there is any firewall / ACL that block the flow.

Anyhow, if you want to leave it as is, then that's OK.   If you decided to explore this a bit further, please let us know your findings.   Thanks.

Hi,Sompholboonjing

Actually i still have mtp checked on the sip trunk.Can't change it now cause this is a production network.

But may be in offhours will uncheck the mtp and see if there is one way voice again or no.

About ITSP,i think they are only supporting rtp-nte,i guess this because this is only option i see offered from their side when debug ccsip messages used.

Thank again man.

This is our call-flow produced by TranslatorX from ccsip debug log on CUBE.   This is an outgoing call made from 7945 phone from CUCM-A to a Jabber client on the far-end.  The CUBE is configured for "flow through" mode.    The "pass-thru content sdp" is not being used and CUBE is not configured to handle mid-call. 

There are three phases in this call.  [1] Call Establishment  [2] After the 7945 phone press "Hold" and the "SDP (inactive)" exchange is done [3] The CUCM-A send "INVITE (without SDP)" to the Jabber client.

At 10:30:03.936 - CUBE Re-INVITE (103 INVITE) toward the Jabber client.

At 10.30:04.140 - CUBE received 200 OK w/SDP (103 INVITE)

At this point CUBE supposed to send out ACK to the far-end, but it doesn't.   So, the "200 OK/w SDP (103 INVITE)" keep being resent back to CUBE.  

This is not happening if the other side is a Cisco phone.

While we can blame it on whatever malformed 200 OK that is received that cause the problem, the real problem is that CUBE has every right to reject that but it doesn't.   The call went dead eventually.   

Hi,

Looking at the sip ladder trace analysis, I am tempted to say that in the case where a call hold between a cisco phone and a jabber client fails/is broken, its almost down the 200 OK received from the SBC..

The steps below details how call transfer/hold works with sip signalling (CUCM and CUBE)

For SIP signalling. when the first transfer key is pressed/hold key

1. CUCM sends invite (re-invite) with an inactive SDP (a=inactive) to indicate a break in media path

--we can see this was the case from your logs

2. CUCM sends a Delayed offer to insert MOH or to resume Media stream

we also saw a DO sent to CUBE

.NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK

Here is where thing usually break. I suggest you look at the 200 OK received from the SBC..what is contained in the offer? is inactive?

3.CUCM establishes newcall leg with the intended transfered destination..Once this call is connected

4.CUCM receives a new Transfer instruction from the transferring phone to connect the held party

5. Next CUCM sends a re-invite with an inactive SDP to indicate a break in media path to MOH (in attempt to complete transfer)

6.Next CUCM sends an inactive SDP to indicate a break in media path between transfering party & transfered party to remove Xferring party from call

7. Next CUCM sends a DO re-invite to connect the transfered party. The far end then sends 200 OK with the required SDP to connect the call

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Hi @aokanlawon,

Thank you very much for the detail explanation of the steps.  It is helpful to understand the call flow in detail.  

I am also glad that you look into this one in particular because I think it is a bug, but I don't want to open the TAC case, which I expect that I would have to jump through the hoops simply to hand the information in (well, on the plate too). 

2. CUCM sends a Delayed offer to insert MOH or to resume Media stream

we also saw a DO sent to CUBE

.NB: CUCM expects a sendrecv offer with SDP to the DO. (NB:if cucm gets an inactive offer SDP in the 200 OK instead of providing a send-recv offer SDP, the media path remains in an inactive state and causes calls to dropcall will drop),CUCM sends an ACK with sendonly to the 200 OK

Here is where thing usually break. I suggest you look at the 200 OK received from the SBC..what is contained in the offer? is inactive?

The DO RE-INVITE is happening at time 10:30:03.932 (CUCM->CUBE) and 10:30:03.936 (CUBE->SBC).

=================================================================

Sep 11 10:30:03.936: //69305/47D1F6000004/SIP/Msg/ccsipDisplayMsg:

Sent:

INVITE sip:+REMOTE_DN@FAR_END_SBC_IP:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP CUBE_IP:5060;branch=z9hG4bK79923D1

From: ;tag=5226AFD8-E3

To: ;tag=1355766~968f888f-ba3a-4701-bd83-3fce8ea74ec4-36044009

Date: Wed, 11 Sep 2013 00:30:03 GMT

Call-ID: 1ED9066E-19B011E3-916A8BFC-ED9F96AC@CUBE_IP

Supported: timer,resource-priority,replaces,sdp-anat

Min-SE:  1800

Cisco-Guid: 1204942336-0000065536-0000269049-3255516170

User-Agent: Cisco-SIPGateway/IOS-15.2.2.T1

Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER

CSeq: 103 INVITE

Max-Forwards: 70

Timestamp: 1378859403

Contact:

Expires: 180

Allow-Events: kpml, telephone-event

Session-Expires:  1800;refresher=uas

Content-Length: 0

=================================================================

Here is where thing usually break. I suggest you look at the 200 OK received from the SBC..what is contained in the offer?
is inactive?

The response from SBC @ 10:30:04.140

=================================================================

Sep 11 10:30:04.140: //69305/47D1F6000004/SIP/Msg/ccsipDisplayMsg:

Received:

SIP/2.0 200 OK

Via: SIP/2.0/TCP CUBE_IP:5060;branch=z9hG4bK79923D1

From: ;tag=5226AFD8-E3

To: ;tag=1355766~968f888f-ba3a-4701-bd83-3fce8ea74ec4-36044009

Call-ID: 1ED9066E-19B011E3-916A8BFC-ED9F96AC@CUBE_IP

CSeq: 103 INVITE

Timestamp: 1378859403

Date: Wed, 11 Sep 2013 00:30:03 GMT

Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY

Allow-Events: presence, kpml

Supported: replaces

Supported: X-cisco-srtp-fallback

Supported: Geolocation

Session-Expires: 1800;refresher=uas

Require: timer

Remote-Party-ID: "JabberUser FullName" <8449>;party=called;screen=yes;privacy=off

Contact: <>

Content-Type: application/sdp

Content-Length: 1064

v=0

o=CiscoSystemsCCM-SIP 1355766 3 IN IP4 FAR_END_SBC_MEDIA_IP

s=SIP Call

b=TIAS:4000000

b=AS:4000

t=0 0

m=audio 58370 RTP/AVP 104 105 0 8 18 101

c=IN IP4 FAR_END_SBC_MEDIA_IP

a=rtpmap:104 G7221/16000

a=fmtp:104 bitrate=32000

a=rtpmap:105 G7221/16000

a=fmtp:105 bitrate=24000

a=rtpmap:0 PCMU/8000

a=ptime:20

a=rtpmap:8 PCMA/8000

a=ptime:20

a=rtpmap:18 G729/8000

a=ptime:20

a=fmtp:18 annexb=no

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

m=video 58350 RTP/AVP 97

c=IN IP4 FAR_END_SBC_MEDIA_IP

b=TIAS:4000000

a=label:11

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=42E01F;packetization-mode=0;max-fs=3601;level-asymmetry-allowed=1

a=imageattr:97 recv [x=[32:1:1280],y=[18:1:720],par=1.7778,q=1.00]

a=content:main

m=video 58322 RTP/AVP 97

c=IN IP4 FAR_END_SBC_MEDIA_IP

b=TIAS:4000000

a=label:12

a=rtpmap:97 H264/90000

a=fmtp:97 profile-level-id=42E01F;packetization-mode=0;max-fs=3601;level-asymmetry-allowed=1

a=content:slides

m=application 58398 UDP/BFCP *

c=IN IP4 FAR_END_SBC_MEDIA_IP

a=floorctrl:c-s

a=floorid:2 mstrm:12

a=confid:7

a=userid:7

=================================================================

This one shows the call flow of the similar call process - call establishment, caller press Hold, caller press UnHold.  (A couple of times may be) and call hang up.   Same settings apart from that the other side is just a Cisco IP Phone and not a (video-capable) Jabber client.

I couldn't quite getting my head around this in detail.   But starting from Re-INVITE (103 INVITE) the call flow seems to change from the above diagram.

The next diagram is for the call flow that CUBE handle the midcall.   (i.e. CUBE maintain the call-leg to the far-end, and only establish/re-establish the call leg between itself and the CUCM)

This works fine with audio-call.   It doesn't work well at all with Video call, after a video call is put on hold, the picture is not coming back on after the call is unhold.    (I doubt that this will work in case of audio-call being escalated to video-call via Call Transfer to a video-capable device.)

Adam Hinchliff
Level 1
Level 1

Hi Somphol,

 

Would you expect to see odd issues occuring if you have both items added to your dial peers?

 

asymmetric payload ful

pass-thru content sdp

 

Or would pass-thru override asymmetric?

 

Thank you

Adam

 

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: