In the larger debug attachment the SDP includes a=fmtp:18 in the 200 OK coming from the CME site (IP 3.3.3.3). In the other capture I didn’t see any SDP. If no DTMF offer is present during call setup, this would assume plain old in-band DTMF, which won’t work on a compressed codec like G.729. You press digits and nothing happens. G729 requires RFC 2833, SIP NOTIFY, or KPML to function properly.
On Jan 30, 2014, at 1:05 PM, Vignesh Sethuraman <[email protected]> wrote: > Hello All, > > I have attached the debug ccsip messages output before and after using the > command. I do not have the answer why it resolved the dtmf-issue. If you guys > find something, please share it. > > Thanks, > Viki > > > > > > On Thu, Jan 30, 2014 at 4:16 PM, Moataz <[email protected]> wrote: > no supplementary service affect only call forwarding and call transfer , i do > not know how it solve DTMF > > Regards, > Moataz Tolba > > > On Thursday, 30 January 2014, 15:17, Mark Holloway <[email protected]> > wrote: > I understand how DTMF works on SIP Trunks, what I’m not clear on is how “no > supp services” would have an impact on his DTMF issue. I’m trying to > understand the logic of something changing with RFC2833 or SIP NOTIFY to the > point where # is now recognized, yet without changing anything related to > DTMF. Wouldn’t supp services only impact the signlaing behavior of the SIP > 302 message itself? But not DTMF? > > > On Jan 30, 2014, at 8:00 AM, Bill Lake <[email protected]> wrote: > >> Inbound SIP trunk from ITSP and CUE >> >> http://www.cisco.com/en/US/products/sw/voicesw/ps4625/products_configuration_example09186a00808f9666.shtml >> >> >> He would see the issue in the debugs >> >> >> >> >> On Thu, Jan 30, 2014 at 6:51 AM, Mark Holloway <[email protected]> wrote: >> Something doesn’t seem to add up in my head. Supp Services shouldn’t effect >> DTMF. Did you change anything related to the SIP Trunk on CUCM? Or anything >> DTMF related on a dial-peer? >> >> On Jan 30, 2014, at 6:22 AM, Vignesh Sethuraman <[email protected]> >> wrote: >> >>> Hello Somphol/Justin, >>> >>> I have resolved the issue by adding the command "no supplementary-service >>> sip moved-temporarily". >>> >>> Thanks a lot Somphol for pointing the document to me. >>> >>> Thank you Justin for providing me the inputs. >>> >>> Regards, >>> Viki >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Jan 30, 2014 at 6:15 AM, Justin Carney <[email protected]> >>> wrote: >>> I concur with Somphol's suggestion and that mtp shouldn't be required. >>> You stated you can record the voicemail but I don't see the "sdspfarm tag 1 >>> BR2-IOS-XCODE" command under telephony-service. Is your transcoder showing >>> its registered with "show sccp" command? I'm guessing that it is >>> registered else you wouldn't be getting to cue using g729 that is coming >>> over the wan (maybe the tag command just got lost on the copy/paste of the >>> config to the email?). >>> (Also for the sccp config you're missing the same tag command for the cfb >>> and the "conference hardware" command. You have the sccp ccm pointing to >>> the cucm ip after cme, are you trying to register sccp resources to cucm?) >>> You can run "debug ccsip messages" on cme to ensure you see the dtmf comes >>> across the sip trunk from cucm. >>> Dial peer 3600 for cue lists dtmf-relay sip-notify and just double check >>> this is set the same inside cue. >>> For an alternate test, when you place the same call can you leave a message >>> (> 2 sec) and hang up without pressing pound? Does the mwi come on and can >>> the cme phone retrieve the voicemail after entering the pin? If so use the >>> same "debug ccsip messages" cmd to see the expected/normal debug output for >>> the dtmf on this working scenario. >>> Hope this helps... >>> -Justin >>> (Sent from my phone, please excuse and/or laugh at any typos.) >>> On Jan 29, 2014 5:40 PM, "Somphol Boonjing" <[email protected]> wrote: >>> >>> On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman >>> <[email protected]> wrote: >>> Media Termination Point Required (Checked) >>> MTP Preferred Originating CodecRequired Field: g711ulaw >>> >>> Hi Vignesh, >>> >>> I think if you can set these two to default settings which is MTP Required >>> [uncheck], and MTP Prefered Codec: <None>, Leave the DTMF Signaling Method >>> to No Preference. Reset the SIP Trunk. >>> >>> You shouldn't need MTP for this operation. >>> >>> Then, if you really want to experiment with MTP insertion, I think you may >>> find this article interesting - >>> http://www.ucguerrilla.com/2012/12/ccie-v-i-shoulda-checked-that-tip-3-mtp.html. >>> >>> Regards, >>> --Somphol. >>> >>> >>> >>> _______________________________________________ >>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >>> >>> iPexpert on YouTube: www.youtube.com/ipexpertinc >>> >>> _______________________________________________ >>> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >>> >>> iPexpert on YouTube: www.youtube.com/ipexpertinc >> >> >> _______________________________________________ >> Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: >> >> iPexpert on YouTube: www.youtube.com/ipexpertinc >> > > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc > > > > _______________________________________________ > Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: > > iPexpert on YouTube: www.youtube.com/ipexpertinc > > <dtmf><dtmf>
_______________________________________________ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
