Depends on the device capabilities involved in the call. What I'm saying
is, limiting your DTMF to inband only is a bad idea, and opening it up to
OOB as well as inband is a better idea. Since most CTI based applications,
which includes call center, do not support Inband DTMF, you will be
invokin
Interesting. Hundreds of millions of never saw that issue. I wonder if that
was a carrier specific setting. Cause they did some really screwy things that
I haven’t seen with other carriers
Kent
> On Mar 31, 2018, at 18:56, Anthony Holloway
> wrote:
>
> Don't do that. That's a sure fire
Don't do that. That's a sure fire way to invoking MTPs for flows that
don't need it, when your CUBE will happily inter-work Inband to OOB.
On Fri, Mar 30, 2018 at 10:38 PM Kent Roberts wrote:
> Put the NTE first, or if you can only use NTE.
>
>
> On Mar 30, 2018, at 9:10 PM, GR wrote:
>
> Thx
One thing to watch out for, or keep in the back of your mind. Do you know if
your carrier will route customer to customer calls on net?I had an issue
with a carrier. One of their customers only did G711 and we offered G729 to
start, and it would kill the call, since the vendor didn’t norma
Yeah - it was initially rtp-nte only (both internal and provider facing) but
some sites could only do out of band and I wanted to steer clear of using MTPs
- so added kpml on top of rtp nte. It works fine now and without the need for
mtp.
Sent from my iPhone
> On 31 Mar 2018, at 2:38 pm, Kent
Put the NTE first, or if you can only use NTE.
> On Mar 30, 2018, at 9:10 PM, GR wrote:
>
> Thx Anthony. Just an update, did that and interworking works fine between
> kpml and rtp nte.
>
> Was enquiring abt digit drop to follow a proactive approach rather than
> reactive. So far its ok wit
Thx Anthony. Just an update, did that and interworking works fine between kpml
and rtp nte.
Was enquiring abt digit drop to follow a proactive approach rather than
reactive. So far its ok without that - but I still have few pending sites so
not implemented globally yet.
Sent from my iPhone
I have had to add digit-drop to the dial-peers when calls were heading to
CUC, but not 100% of the time. As with a lot of things, don't configure
something just to configure it. Know that it's needed first, then
configure it. Else you end up with this giant configuration that you
cannot explain
Thanks Anthony. So no need to configure digit drop ? Even if I am doing RFC2833
on one leg and advertise both Inband and OOB on second leg.
Sent from my iPhone
> On 16 Mar 2018, at 2:10 am, Anthony Holloway
> wrote:
>
> I was going to mention that CUBE doesn't support rtp-nte to sip-kpml
>
I was going to mention that CUBE doesn't support rtp-nte to sip-kpml
interworking. Weird, I know. But that's how it was. However, when I went
to grab the link for my source, the table has been updated, and I see that
this is now supported.
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice
half Of GR
Sent: 15 March 2018 19:13
To: cisco-voip@puck.nether.net
Subject: [cisco-voip] CUBE DTMF
Hi Guys,
I am having an issue with SIP provider only supporting rfc2833. The CUBEs are
configured only for rtp-nte on all dial-peers facing both the provider and the
CUCM internal network (mu
Hi Guys,
I am having an issue with SIP provider only supporting rfc2833. The CUBEs are
configured only for rtp-nte on all dial-peers facing both the provider and the
CUCM internal network (multiple clusters)
Randomly one of the MGCP/h323 gateway is having issues, where it only supports
OOB and
12 matches
Mail list logo
