[prev in list] [next in list] [prev in thread] [next in thread]
List: cisco-voip
Subject: Re: [cisco-voip] CUBE and LTI for MTPs
From: Anthony Holloway <avholloway+cisco-voip () gmail ! com>
Date: 2016-07-08 20:31:08
Message-ID: CACRCJOiGOgcF=1Gr6J2anMUR6dcJMJh0NrxMH1ivY2VSxi2PPQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
I use rtp-nte to SIP KPML in CUBE quite a bit actually, despite the
documentation saying it's not supported. I also use digit-drop too by the
way, because on more than one occasion I have had double DTMF issues.
E.g., dtmf-relay sip-kpml rtp-nte digit-drop
Also, unless you like using MTPs in your some of call flows (E.g., UCCX),
you should have one OOB and one inband DTMF offering on your dial-peers.
It surprises me how often I see and hear of people only putting rtp-nte on
there.
On Thu, Jul 7, 2016 at 7:20 PM, Ed Leatherman <ealeatherman@gmail.com>
wrote:
> I've been beating my head on this all day, glad I ran across this thread
> as it at least seems to rule out one potential issue on my current SIP
> puzzle :)
>
> I've found 2 different documents with tables that suggest KPML <> rpt-nte
> shouldn't work... i realize its over a year since this thread popped in -
> has anyone ever seen something to the contrary in official documentation?
>
> On Tue, Mar 31, 2015 at 11:54 AM, Anthony Holloway <
> avholloway+cisco-voip@gmail.com> wrote:
>
> > After reading a bit more in the CUCM SRND, I see that SIP INFO is not
> > supported by CUCM, and furthermore, Cisco's preferred OOB method is KPML.
> >
> > "Out-of-band (OOB) SIP DTMF signalling methods include Unsolicited Notify
> > (UN), Information
> > (INFO), and Key Press Mark-up Language (KPML). KPML (RFC 4730) is the OOB
> > signalling method
> > preferred by Cisco and is supported by Cisco Unified CM, Cisco IOS
> > platforms (Release 12.4 and later),
> > and most models of Cisco Unified IP Phones. INFO is not supported by
> > Unified CM."
> > Source:
> > http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab10/collab10/trunks.html#pgfId-1346554
> >
> > With that said, according to the link you provided on CUBE and DTMF
> > inter-working, it would appear as though the only option which remains is
> > SIP NOTIFY. This method requires the SIP Trunk Security Profile to have
> > the Accept unsolicited notification checkbox checked.
> >
> > I did test with KPML, and CUBE did inter-work it. My IOS/CUBE version is
> > as follows:
> >
> > *CUBE#sh cube status | in Version*
> > *CUBE-Version : 10.0.2*
> > *SW-Version : 15.4.3.M2, Platform CISCO2921/K9*
> >
> > I think I'll go with KPML for now, and thank you for helping me to see
> > the light.
> >
> > On Mon, Mar 30, 2015 at 1:52 PM Brian Meade <bmeade90@vt.edu> wrote:
> >
> > > This chart has all the interoperability that can be handled by
> > > dtmf-relay natively on CUBE-
> > > http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561
> > >
> > > Brian
> > >
> > > On Mon, Mar 30, 2015 at 2:29 PM, Brian Meade <bmeade90@vt.edu> wrote:
> > >
> > > > dtmf-relay I believe should handle that find for you without the MTP.
> > > >
> > > > On Mon, Mar 30, 2015 at 1:21 PM, Anthony Holloway <
> > > > avholloway+cisco-voip@gmail.com> wrote:
> > > >
> > > > > Oooo, good question Brian. It's my understanding that in order for
> > > > > the below specific call flow to work, an MTP is required for DTMF
> > > > > inter-working of inband to out-of-band.
> > > > >
> > > > > PSTN Caller Pushes DTMF ---> ITSP Delivers RFC2833 ---> CUBE Delivers
> > > > > OOB ---> CUCM Devlier OOB ---> UCCX CTI Port Receives OOB
> > > > >
> > > > > Is that not the case?
> > > > >
> > > > > On Mon, Mar 30, 2015 at 12:01 PM Brian Meade <bmeade90@vt.edu> wrote:
> > > > >
> > > > > > What are you trying to accomplish with the MTP that can't already be
> > > > > > accomplished with media flow-through and dtmf-relay?
> > > > > >
> > > > > > On Mon, Mar 30, 2015 at 12:38 PM, Anthony Holloway <
> > > > > > avholloway+cisco-voip@gmail.com> wrote:
> > > > > >
> > > > > > > All,
> > > > > > >
> > > > > > > I know the name itself, LTI, includes the word transcoding, but I'm
> > > > > > > just double checking that this will or will not work for registering an \
> > > > > > > MTP on the CUBE. All roads are leading me to the answer, but it just \
> > > > > > > seems like a huge miss on Cisco's part to not allow us to register MTPs \
> > > > > > > as well as XCODE via the LTI method.
> > > > > > >
> > > > > > > This works for me:
> > > > > > > dspfarm profile 1 transcode
> > > > > > > codec g711ulaw
> > > > > > > codec g729ar8
> > > > > > > max sessions 1
> > > > > > > assoc app cube
> > > > > > > no shut
> > > > > > > !
> > > > > > >
> > > > > > > This does not work for me (it hangs on associating to cube app):
> > > > > > > dapfarm profile 2 mtp
> > > > > > > codec g711ulaw
> > > > > > > max sessions software 1
> > > > > > > assoc app cube
> > > > > > > no shut
> > > > > > > !
> > > > > > >
> > > > > > > I have the required dspfarm and mode border-element commands, and
> > > > > > > rebooted after as well.
> > > > > > >
> > > > > > > Seems like with the standard requirement of rfc2833 on SIP trunks to
> > > > > > > the ITPS, and CTI apps in the network (I'm looking at you UCCX), MTPs \
> > > > > > > play a large role in the success of SIP trunking for customers, and yet \
> > > > > > > I cannot even register them locally with the LTI.
> > > > > > >
> > > > > > > I do have a fallback plan, so I'm not stuck. I'm just looking for
> > > > > > > the optimal design scenario. In my order of preference I would like to \
> > > > > > > go:
> > > > > > > 1. LTI
> > > > > > > 2. SCCP via Telephony Service
> > > > > > > 3. SCCP via CUCM
> > > > > > >
> > > > > > > Would you rank them differently?
> > > > > > >
> > > > > > > Thanks for your input in advance.
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > cisco-voip mailing list
> > > > > > > cisco-voip@puck.nether.net
> > > > > > > https://puck.nether.net/mailman/listinfo/cisco-voip
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> > >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip@puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
>
>
> --
> Ed Leatherman
>
[Attachment #5 (text/html)]
<div dir="ltr">I use rtp-nte to SIP KPML in CUBE quite a bit actually, despite the \
documentation saying it's not supported. I also use digit-drop too by the way, \
because on more than one occasion I have had double DTMF \
issues.<div><br></div><div>E.g., dtmf-relay sip-kpml rtp-nte \
digit-drop</div><div><br></div><div>Also, unless you like using MTPs in your some of \
call flows (E.g., UCCX), you should have one OOB and one inband DTMF offering on your \
dial-peers. It surprises me how often I see and hear of people only putting rtp-nte \
on there.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, \
Jul 7, 2016 at 7:20 PM, Ed Leatherman <span dir="ltr"><<a \
href="mailto:ealeatherman@gmail.com" \
target="_blank">ealeatherman@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">I've been beating my head on this all day, \
glad I ran across this thread as it at least seems to rule out one potential issue on \
my current SIP puzzle :)<div><br></div><div>I've found 2 different documents with \
tables that suggest KPML <> rpt-nte shouldn't work... i realize its over a \
year since this thread popped in - has anyone ever seen something to the contrary in \
official documentation? </div></div><div class="gmail_extra"><div><div \
class="h5"><br><div class="gmail_quote">On Tue, Mar 31, 2015 at 11:54 AM, Anthony \
Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" \
target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">After reading a bit more in the CUCM SRND, I \
see that SIP INFO is not supported by CUCM, and furthermore, Cisco's preferred \
OOB method is KPML.<div><br></div><div>"Out-of-band (OOB) SIP DTMF signalling \
methods include Unsolicited Notify (UN), Information</div><div>(INFO), and Key Press \
Mark-up Language (KPML). KPML (RFC 4730) is the OOB signalling \
method</div><div>preferred by Cisco and is supported by Cisco Unified CM, Cisco IOS \
platforms (Release 12.4 and later),</div><div>and most models of Cisco Unified IP \
Phones. INFO is not supported by Unified CM."</div><div>Source: <a \
href="http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab10/collab10/trunks.html#pgfId-1346554" \
target="_blank">http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/srnd/collab10/collab10/trunks.html#pgfId-1346554</a><br><div><br></div><div>With \
that said, according to the link you provided on CUBE and DTMF inter-working, it \
would appear as though the only option which remains is SIP NOTIFY. This method \
requires the SIP Trunk Security Profile to have the Accept unsolicited notification \
checkbox checked.</div><div><br></div><div>I did test with KPML, and CUBE did \
inter-work it. My IOS/CUBE version is as \
follows:</div><div><br></div><div><div><div><b>CUBE#sh cube status | in \
Version</b></div><div><b>CUBE-Version : 10.0.2</b></div><div><b>SW-Version : \
15.4.3.M2, Platform CISCO2921/K9</b></div></div><div><br></div><div>I think I'll \
go with KPML for now, and thank you for helping me to see the \
light.</div><div><div><br><div class="gmail_quote">On Mon, Mar 30, 2015 at 1:52 PM \
Brian Meade <<a href="mailto:bmeade90@vt.edu" \
target="_blank">bmeade90@vt.edu</a>> wrote:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr">This chart has all the interoperability that can be handled by dtmf-relay \
natively on CUBE- <a \
href="http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561" \
target="_blank">http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configurat \
ion/cube-book/dtmf-relay.html#concept_264617919921874995299551391601561</a></div><div \
dir="ltr"><div><br></div><div>Brian</div></div><div class="gmail_extra"><br><div \
class="gmail_quote">On Mon, Mar 30, 2015 at 2:29 PM, Brian Meade <span \
dir="ltr"><<a href="mailto:bmeade90@vt.edu" \
target="_blank">bmeade90@vt.edu</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">dtmf-relay I believe should handle that find \
for you without the MTP.</div><div><div><div class="gmail_extra"><br><div \
class="gmail_quote">On Mon, Mar 30, 2015 at 1:21 PM, Anthony Holloway <span \
dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" \
target="_blank">avholloway+cisco-voip@gmail.com</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">Oooo, good question Brian. It's my \
understanding that in order for the below specific call flow to work, an MTP is \
required for DTMF inter-working of inband to out-of-band.<br><br><div>PSTN Caller \
Pushes DTMF ---> ITSP Delivers RFC2833 ---> CUBE Delivers OOB ---> CUCM \
Devlier OOB ---> UCCX CTI Port Receives OOB</div><div><br></div><div><span \
style="line-height:1.5;font-size:13.1999998092651px">Is that not the \
case?</span><br></div></div><div><div><br><div class="gmail_quote">On Mon, Mar 30, \
2015 at 12:01 PM Brian Meade <<a href="mailto:bmeade90@vt.edu" \
target="_blank">bmeade90@vt.edu</a>> wrote:<br><blockquote class="gmail_quote" \
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div \
dir="ltr">What are you trying to accomplish with the MTP that can't already be \
accomplished with media flow-through and dtmf-relay?</div><div \
class="gmail_extra"><br><div class="gmail_quote"></div></div><div \
class="gmail_extra"><div class="gmail_quote">On Mon, Mar 30, 2015 at 12:38 PM, \
Anthony Holloway <span dir="ltr"><<a href="mailto:avholloway+cisco-voip@gmail.com" \
target="_blank">avholloway+cisco-voip@gmail.com</a>></span> \
wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex"><div dir="ltr">All,<div><br></div><div>I know the name \
itself, LTI, includes the word transcoding, but I'm just double checking that \
this will or will not work for registering an MTP on the CUBE. All roads are \
leading me to the answer, but it just seems like a huge miss on Cisco's part to \
not allow us to register MTPs as well as XCODE via the LTI \
method.</div><div><br></div><div>This works for me:</div><div>dspfarm profile 1 \
transcode</div><div> codec g711ulaw</div><div> codec g729ar8</div><div> max \
sessions 1</div><div> assoc app cube</div><div> no \
shut</div><div>!</div><div><br></div><div>This does not work for me (it hangs on \
associating to cube app):</div><div>dapfarm profile 2 mtp</div><div> codec \
g711ulaw</div><div> max sessions software 1</div><div> assoc app cube</div><div> \
no shut</div><div>!</div><div><br></div><div>I have the required dspfarm and mode \
border-element commands, and rebooted after as well.</div><div><br></div><div>Seems \
like with the standard requirement of rfc2833 on SIP trunks to the ITPS, and CTI apps \
in the network (I'm looking at you UCCX), MTPs play a large role in the success \
of SIP trunking for customers, and yet I cannot even register them locally with the \
LTI.</div><div><br></div><div>I do have a fallback plan, so I'm not stuck. \
I'm just looking for the optimal design scenario. In my order of preference I \
would like to go:</div><div><br></div><div>1. LTI</div><div>2. SCCP via Telephony \
Service</div><div>3. SCCP via CUCM</div><div><br></div><div>Would you rank them \
differently?</div><div><br></div><div>Thanks for your input in advance.</div></div> \
<br></blockquote></div></div><div class="gmail_extra"><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc \
solid;padding-left:1ex">_______________________________________________<br> \
cisco-voip mailing list<br> <a href="mailto:cisco-voip@puck.nether.net" \
target="_blank">cisco-voip@puck.nether.net</a><br> <a \
href="https://puck.nether.net/mailman/listinfo/cisco-voip" \
target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br> \
<br></blockquote></div><br></div> </blockquote></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div></div></div></div></div></div>
<br>_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" \
target="_blank">cisco-voip@puck.nether.net</a><br> <a \
href="https://puck.nether.net/mailman/listinfo/cisco-voip" rel="noreferrer" \
target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br> \
<br></blockquote></div><br><br clear="all"><div><br></div></div></div><span \
class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature">Ed \
Leatherman<br></div> </font></span></div>
</blockquote></div><br></div>
_______________________________________________
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic