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
