09-12-2013 12:40 AM - edited 03-16-2019 07:19 PM
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
09-12-2013 01:58 AM
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
09-12-2013 02:40 AM
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..
09-16-2013 01:48 AM
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.
09-16-2013 02:45 AM
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.
09-16-2013 03:25 AM
Excellent Mr.Sompholboonjing
Great when i used rtp nte only.The dtmf worked and no one way voice.
GREAT.Thanks man so so much
09-16-2013 03:46 AM
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.
09-16-2013 05:06 AM
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.
09-12-2013 04:42 PM
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.
09-17-2013 04:15 AM
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"
09-18-2013 04:43 PM
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:
To:
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:
To:
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=off8449>
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
=================================================================
09-12-2013 05:05 PM
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.
09-12-2013 05:18 PM
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.)
09-04-2017 10:52 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide