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 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 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 > 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 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 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 >> 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 >>> 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" wrote: >>> >>> On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman >>> 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: , 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 >> >> >> __
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 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 > 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 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 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 > 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 > 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" 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: , 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 Description: Binary data dtmf Description: Binary data ___ Free CCIE R&S, Collaboration, Data Center, Wireless & Security Vide
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" 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 > 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" 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" 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 >
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! 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 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" 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" 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
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 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" 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" 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 Patt
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" 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" 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 = S
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" 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 Nu
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] 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 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 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 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 >>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 >>>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" wrote: > >On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman > 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: , 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
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 Sender: ccie_voice-boun...@onlinestudylist.com Date: Thu, 30 Jan 2014 08:29:46 To: Subject: [OSL | CCIE_Voice] 2nd LD call fails ___ 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
[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 R&S, 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 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 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 > 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 >> 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" wrote: >> >> On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman >> 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: , 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
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 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 > 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" wrote: > > On Thu, Jan 30, 2014 at 8:48 AM, Vignesh Sethuraman > 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: , 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
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 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" 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: , 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
