Re: [OSL | CCIE_Voice] DTMF Issue with SIP TRUNK (CUCM and CUE)
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 justin.s.car...@gmail.comwrote: 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 somp...@gmail.com wrote: On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman sethuvign...@gmail.com 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 RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
Re: [OSL | CCIE_Voice] DTMF Issue with SIP TRUNK (CUCM and CUE)
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 sethuvign...@gmail.com 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 justin.s.car...@gmail.com 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 somp...@gmail.com wrote: On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman sethuvign...@gmail.com 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 RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
Re: [OSL | CCIE_Voice] DTMF Issue with SIP TRUNK (CUCM and CUE)
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 whl...@gmail.com 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 m...@markholloway.com 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 sethuvign...@gmail.com 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 justin.s.car...@gmail.com 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 somp...@gmail.com wrote: On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman sethuvign...@gmail.com 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 RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
[OSL | CCIE_Voice] 2nd LD call fails
Hope someone can help with this issue I'm having. I am using ucm 8.6 with mgcp gateways with a pri on the gw. Any user at the site can place a LD call and it work fine...second user tries to make an LD call and they get reorder tone when there are available channels. Could anyone give some insight on what I could look for? ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
Re: [OSL | CCIE_Voice] 2nd LD call fails
Check if the route list get exhausted and need a rest Do you have traces for the failing call ? Moataz -Original Message- From: Mike O'Nan mdona...@gmail.com Sender: ccie_voice-boun...@onlinestudylist.com Date: Thu, 30 Jan 2014 08:29:46 To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] 2nd LD call fails ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
Re: [OSL | CCIE_Voice] DTMF Issue with SIP TRUNK (CUCM and CUE)
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 m...@markholloway.com 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 whl...@gmail.com 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 m...@markholloway.com 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 sethuvign...@gmail.com 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 justin.s.car...@gmail.com 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 somp...@gmail.com wrote: On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman sethuvign...@gmail.com 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 RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc
Re: [OSL | CCIE_Voice] 2nd LD call fails
Here are the debugs from the MGCP GW: RTR-02#debug isdn q931 RTR-02#debug ccm-manager backhaul packets Call Manager backhaul packets debugging is on RTR-02# Jan 30 08:19:12.546: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008E0504038090A21803A98397200200F36C06218137353739700CA13132373035373732383332 Jan 30 08:19:12.546: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008E Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7579' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1270XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:12.578: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808E Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:12.578: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808E7D080282E4140101 Jan 30 08:19:12.638: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808E Cause i = 0x8295 - Call rejected Jan 30 08:19:12.638: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808E5A08028295 Jan 30 08:19:27.486: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008F0504038090A21803A98397200200F36C06218137353834700CA13138313232353038343038 Jan 30 08:19:27.490: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008F Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7584' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1812XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:27.518: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808F Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:27.518: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808F7D080282E4140101 Jan 30 08:19:27.574: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808F Cause i = 0x8295 - Call rejected Jan 30 08:19:27.574: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808F5A08028295 DNA from CUCM: Results Summary Calling Party Information Calling Party = 610XXX Characters hidden Partition = Internal Device CSS = SiteLD-CSS Line CSS = SiteLD-CSS AAR Group Name = AAR CSS = Dialed Digits = 91270XXX Characters hidden Match Result = RouteThisPattern Matched Pattern Information Pattern = 9.1[2-9]XX[2-9]XX Partition = LD-Site Time Schedule = Called Party Number = 1270XXX Characters hidden Time Zone = America/New_York End Device = Site-RL Call Classification = OffNet InterDigit Timeout = NO Device Override = Disabled Outside Dial Tone = NO Call Flow TranslationPattern :Pattern= Partition = Positional Match List = 1270XXX Characters hidden Calling Party Number = 610XXX Characters hidden PreTransform Calling Party Number = PreTransform Called Party Number = Calling Party Transformations External Phone Number Mask = NO Calling Party Mask =
Re: [OSL | CCIE_Voice] 2nd LD call fails
I just noticed in the trace Outside Dial Tone = NO. I have also confirmed the LD pattern is not set for off net. Interesting that when I set to off net it does not give secondary dial tone until the 3rd digit is dialed. I just watched a video yesterday on how to change that but can't remember off the top of my head? On Jan 30, 2014 9:40 AM, Mike O'Nan mdona...@gmail.com wrote: Here are the debugs from the MGCP GW: RTR-02#debug isdn q931 RTR-02#debug ccm-manager backhaul packets Call Manager backhaul packets debugging is on RTR-02# Jan 30 08:19:12.546: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008E0504038090A21803A98397200200F36C06218137353739700CA13132373035373732383332 Jan 30 08:19:12.546: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008E Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7579' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1270XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:12.578: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808E Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:12.578: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808E7D080282E4140101 Jan 30 08:19:12.638: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808E Cause i = 0x8295 - Call rejected Jan 30 08:19:12.638: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808E5A08028295 Jan 30 08:19:27.486: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008F0504038090A21803A98397200200F36C06218137353834700CA13138313232353038343038 Jan 30 08:19:27.490: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008F Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7584' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1812XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:27.518: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808F Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:27.518: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808F7D080282E4140101 Jan 30 08:19:27.574: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808F Cause i = 0x8295 - Call rejected Jan 30 08:19:27.574: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808F5A08028295 DNA from CUCM: Results Summary Calling Party Information Calling Party = 610XXX Characters hidden Partition = Internal Device CSS = SiteLD-CSS Line CSS = SiteLD-CSS AAR Group Name = AAR CSS = Dialed Digits = 91270XXX Characters hidden Match Result = RouteThisPattern Matched Pattern Information Pattern = 9.1[2-9]XX[2-9]XX Partition = LD-Site Time Schedule = Called Party Number = 1270XXX Characters hidden Time Zone = America/New_York End Device = Site-RL Call Classification = OffNet InterDigit Timeout = NO Device Override =
Re: [OSL | CCIE_Voice] 2nd LD call fails
Pattern is set off net and I fixed the secondary dial tone...still get reorder tone on 2nd LD call. Any ideas from the debugs I provided? On Jan 30, 2014 9:45 AM, Mike O'Nan mdona...@gmail.com wrote: I just noticed in the trace Outside Dial Tone = NO. I have also confirmed the LD pattern is not set for off net. Interesting that when I set to off net it does not give secondary dial tone until the 3rd digit is dialed. I just watched a video yesterday on how to change that but can't remember off the top of my head? On Jan 30, 2014 9:40 AM, Mike O'Nan mdona...@gmail.com wrote: Here are the debugs from the MGCP GW: RTR-02#debug isdn q931 RTR-02#debug ccm-manager backhaul packets Call Manager backhaul packets debugging is on RTR-02# Jan 30 08:19:12.546: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008E0504038090A21803A98397200200F36C06218137353739700CA13132373035373732383332 Jan 30 08:19:12.546: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008E Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7579' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1270XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:12.578: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808E Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:12.578: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808E7D080282E4140101 Jan 30 08:19:12.638: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808E Cause i = 0x8295 - Call rejected Jan 30 08:19:12.638: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808E5A08028295 Jan 30 08:19:27.486: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008F0504038090A21803A98397200200F36C06218137353834700CA13138313232353038343038 Jan 30 08:19:27.490: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008F Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7584' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1812XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:27.518: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808F Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:27.518: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808F7D080282E4140101 Jan 30 08:19:27.574: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808F Cause i = 0x8295 - Call rejected Jan 30 08:19:27.574: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808F5A08028295 DNA from CUCM: Results Summary Calling Party Information Calling Party = 610XXX Characters hidden Partition = Internal Device CSS = SiteLD-CSS Line CSS = SiteLD-CSS AAR Group Name = AAR CSS = Dialed Digits = 91270XXX Characters hidden Match Result = RouteThisPattern Matched Pattern Information Pattern = 9.1[2-9]XX[2-9]XX Partition = LD-Site Time Schedule = Called Party
Re: [OSL | CCIE_Voice] 2nd LD call fails
I can see the release is coming from the PSTN due to invalid information elements Regards, Moataz Tolba On Thursday, 30 January 2014, 18:08, Mike O'Nan mdona...@gmail.com wrote: Pattern is set off net and I fixed the secondary dial tone...still get reorder tone on 2nd LD call. Any ideas from the debugs I provided? On Jan 30, 2014 9:45 AM, Mike O'Nan mdona...@gmail.com wrote: I just noticed in the trace Outside Dial Tone = NO. I have also confirmed the LD pattern is not set for off net. Interesting that when I set to off net it does not give secondary dial tone until the 3rd digit is dialed. I just watched a video yesterday on how to change that but can't remember off the top of my head? On Jan 30, 2014 9:40 AM, Mike O'Nan mdona...@gmail.com wrote: Here are the debugs from the MGCP GW: RTR-02#debug isdn q931 RTR-02#debug ccm-manager backhaul packets Call Manager backhaul packets debugging is on RTR-02# Jan 30 08:19:12.546: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008E0504038090A21803A98397200200F36C06218137353739700CA13132373035373732383332 Jan 30 08:19:12.546: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008E Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7579' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1270XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:12.578: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808E Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:12.578: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808E7D080282E4140101 Jan 30 08:19:12.638: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808E Cause i = 0x8295 - Call rejected Jan 30 08:19:12.638: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808E5A08028295 Jan 30 08:19:27.486: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008F0504038090A21803A98397200200F36C06218137353834700CA13138313232353038343038 Jan 30 08:19:27.490: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008F Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7584' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1812XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:27.518: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808F Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:27.518: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808F7D080282E4140101 Jan 30 08:19:27.574: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808F Cause i = 0x8295 - Call rejected Jan 30 08:19:27.574: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808F5A08028295 DNA from CUCM: Results Summary Calling Party Information Calling Party = 610XXX Characters hidden Partition = Internal Device CSS = SiteLD-CSS Line CSS = SiteLD-CSS AAR Group Name = AAR CSS = Dialed Digits = 91270XXX Characters hidden Match Result = RouteThisPattern Matched Pattern Information Pattern = 9.1[2-9]XX[2-9]XX Partition = LD-Site Time Schedule = Called Party Number = 1270XXX
Re: [OSL | CCIE_Voice] 2nd LD call fails
Its a full PRI from a carrier. I noticed that as well I was just hoping it was some config error on my end. This carrier is a pain to work with! Thanks for the input! div Original message /divdivFrom: Moataz moataz_m...@yahoo.com /divdivDate:01/30/2014 10:15 AM (GMT-06:00) /divdivTo: Mike O'Nan mdona...@gmail.com /divdivCc: ccie_voice-boun...@onlinestudylist.com,ccie_voice@onlinestudylist.com /divdivSubject: Re: [OSL | CCIE_Voice] 2nd LD call fails /divdiv /divI can see the release is coming from the PSTN due to invalid information elements Regards, Moataz Tolba On Thursday, 30 January 2014, 18:08, Mike O'Nan mdona...@gmail.com wrote: Pattern is set off net and I fixed the secondary dial tone...still get reorder tone on 2nd LD call. Any ideas from the debugs I provided? On Jan 30, 2014 9:45 AM, Mike O'Nan mdona...@gmail.com wrote: I just noticed in the trace Outside Dial Tone = NO. I have also confirmed the LD pattern is not set for off net. Interesting that when I set to off net it does not give secondary dial tone until the 3rd digit is dialed. I just watched a video yesterday on how to change that but can't remember off the top of my head? On Jan 30, 2014 9:40 AM, Mike O'Nan mdona...@gmail.com wrote: Here are the debugs from the MGCP GW: RTR-02#debug isdn q931 RTR-02#debug ccm-manager backhaul packets Call Manager backhaul packets debugging is on RTR-02# Jan 30 08:19:12.546: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008E0504038090A21803A98397200200F36C06218137353739700CA13132373035373732383332 Jan 30 08:19:12.546: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008E Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7579' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1270XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:12.578: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808E Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:12.578: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808E7D080282E4140101 Jan 30 08:19:12.638: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808E Cause i = 0x8295 - Call rejected Jan 30 08:19:12.638: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808E5A08028295 Jan 30 08:19:27.486: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008F0504038090A21803A98397200200F36C06218137353834700CA13138313232353038343038 Jan 30 08:19:27.490: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008F Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7584' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1812XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:27.518: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808F Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:27.518: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808F7D080282E4140101 Jan 30 08:19:27.574: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808F Cause i = 0x8295 - Call rejected Jan 30 08:19:27.574: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808F5A08028295 DNA from CUCM: Results Summary Calling Party Information
Re: [OSL | CCIE_Voice] 2nd LD call fails
As a test you can modify the mgcp setting in cucm to NOT send the outbound IE. This will confirm whether the Telco is rejecting the call due to invalid IE. I recently worked a similar issue where I saw an invalid IE error message (a rouge prefix on a rp caused the ani to be too long) but the calls were still routed by the telco and connected successfully. In this case the issue was cosmetic and the ani was easily corrected. -Justin (Sent from my phone, please excuse and/or laugh at any typos.) On Jan 30, 2014 11:32 AM, Mike O'Nan mdona...@gmail.com wrote: Its a full PRI from a carrier. I noticed that as well I was just hoping it was some config error on my end. This carrier is a pain to work with! Thanks for the input! Original message From: Moataz Date:01/30/2014 10:15 AM (GMT-06:00) To: Mike O'Nan Cc: ccie_voice-boun...@onlinestudylist.com,ccie_voice@onlinestudylist.com Subject: Re: [OSL | CCIE_Voice] 2nd LD call fails I can see the release is coming from the PSTN due to invalid information elements Regards, Moataz Tolba On Thursday, 30 January 2014, 18:08, Mike O'Nan mdona...@gmail.com wrote: Pattern is set off net and I fixed the secondary dial tone...still get reorder tone on 2nd LD call. Any ideas from the debugs I provided? On Jan 30, 2014 9:45 AM, Mike O'Nan mdona...@gmail.com wrote: I just noticed in the trace Outside Dial Tone = NO. I have also confirmed the LD pattern is not set for off net. Interesting that when I set to off net it does not give secondary dial tone until the 3rd digit is dialed. I just watched a video yesterday on how to change that but can't remember off the top of my head? On Jan 30, 2014 9:40 AM, Mike O'Nan mdona...@gmail.com wrote: Here are the debugs from the MGCP GW: RTR-02#debug isdn q931 RTR-02#debug ccm-manager backhaul packets Call Manager backhaul packets debugging is on RTR-02# Jan 30 08:19:12.546: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008E0504038090A21803A98397200200F36C06218137353739700CA13132373035373732383332 Jan 30 08:19:12.546: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008E Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7579' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1270XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:12.578: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808E Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:12.578: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 12 | Q.931 message type: STATUS | Q.931 message = 0802808E7D080282E4140101 Jan 30 08:19:12.638: ISDN Se0/3/1:23 Q931: RX - RELEASE_COMP pd = 8 callref = 0x808E Cause i = 0x8295 - Call rejected Jan 30 08:19:12.638: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931 length = 9 | Q.931 message type: RELEASE COMPLETE | Q.931 message = 0802808E5A08028295 Jan 30 08:19:27.486: cmbh_rcv_callback: -- Receiving backhaul msg for Se0/3/1:23 : | bk_msg_type = DATA_REQ | bk_chan_id (slot:port) = 0:1 | Q.931 length = 41 | Q.931 message type: SETUP | Q.931 message = 0802008F0504038090A21803A98397200200F36C06218137353834700CA13138313232353038343038 Jan 30 08:19:27.490: ISDN Se0/3/1:23 Q931: TX - SETUP pd = 8 callref = 0x008F Bearer Capability i = 0x8090A2 Standard = CCITT Transfer Capability = Speech Transfer Mode = Circuit Transfer Rate = 64 kbit/s Channel ID i = 0xA98397 Exclusive, Channel 23 Net Specific Fac i = 0x00F3 Calling Party Number i = 0x2181, '7584' Plan:ISDN, Type:National Called Party Number i = 0xA1, '1812XXX' Characters hidden Plan:ISDN, Type:National Jan 30 08:19:27.518: ISDN Se0/3/1:23 Q931: RX - STATUS pd = 8 callref = 0x808F Cause i = 0x82E4 - Invalid information element contents Call State i = 0x01 Jan 30 08:19:27.518: cmbrl_send_pak: -- Sending backhauled msg for Se0/3/1:23 : | bk_msg_type = DATA_IND | bk_chan_id (slot:port) = 0:1 | Q.931
Re: [OSL | CCIE_Voice] DTMF Issue with SIP TRUNK (CUCM and CUE)
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 moataz_m...@yahoo.com 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 m...@markholloway.com 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 whl...@gmail.com 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 m...@markholloway.comwrote: 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 sethuvign...@gmail.com 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 justin.s.car...@gmail.comwrote: 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 somp...@gmail.com wrote: On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman sethuvign...@gmail.com 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 RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc dtmf Description: Binary data dtmf Description: Binary data ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube:
Re: [OSL | CCIE_Voice] DTMF Issue with SIP TRUNK (CUCM and CUE)
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 sethuvign...@gmail.com 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 moataz_m...@yahoo.com 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 m...@markholloway.com 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 whl...@gmail.com 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 m...@markholloway.com 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 sethuvign...@gmail.com 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 justin.s.car...@gmail.com 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 somp...@gmail.com wrote: On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman sethuvign...@gmail.com 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 RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube: www.youtube.com/ipexpertinc ___ Free CCIE RS, Collaboration, Data Center, Wireless Security Videos :: iPexpert on YouTube:
