[cisco-voip] SIP Trunk from ISP DTMF issue

[Paul van den IJssel]

My ISP is able to set the DTMF to:

- SIP INFO;

- SIP NOTIFY;

- RFC2833 (payload type 101);



If my ISP sets it to RFC2833 the CUCM should accept it right?


2010/7/13 Matt Slaga (US) <Matt.Slaga at us.didata.com>

> If you are not using a cube, you might need an enhanced IOS software MTP
> termination point which will allow the capturing of DTMF packets inband and
> process them out of band.  These can run as software MTPs on the gateway
> (cannot use the UCM built in software MTPs for this purpose).
>
> ________________________________________
> From: cisco-voip-bounces at puck.nether.net [
> cisco-voip-bounces at puck.nether.net] On Behalf Of Nick Matthews [
> matthnick at gmail.com]
> Sent: Tuesday, July 13, 2010 11:38 AM
> To: Mark Holloway
> Cc: cisco-voip at puck.nether.net; Paul van den IJssel
> Subject: Re: [cisco-voip] SIP Trunk from ISP DTMF issue
>
> Also check the ccn subsystem sip on the CUE - make sure you're
> configured for the DTMF method you're using everywhere else.  Plus use
> a CUBE as stated.
>
> -nick
>
> On Tue, Jul 13, 2010 at 11:17 AM, Mark Holloway <mh at markholloway.com>
> wrote:
> > The Genband is probably doing the same thing that CUBE would be doing.
>  What
> > are the DTMF requirements from your provider?  Have you confirmed that
> DTMF
> > is being passed to the provider?  A Wireshark capture on the public side
> of
> > the S3 would verify DTMF is being passed.
> > On Jul 13, 2010, at 7:58 AM, Bill wrote:
> >
> > You should not trunk directly to CUCM from your ITSP. You need to go
> through
> > a CUBE router. Terminate the ITSP on the CUBE and then do a SIP trunk to
> > your CUBE router.
> >
> > ________________________________
> > From: cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] On
> > Behalf Of Paul van den IJssel
> > Sent: Tuesday, July 13, 2010 9:54 AM
> > To: cisco-voip at puck.nether.net
> > Subject: [cisco-voip] SIP Trunk from ISP DTMF issue
> >
> > Hi all,
> >
> > Currently I'm running a acceptance test on a SIP Trunk from our ISP.
> > Everything is working fine except the DTMF.
> >
> > Setup:
> > [GenBand SBC] ---- [SIP Trunk into CUCM 7.1] ---- [Cisco Unity Express
> 7.0]
> >
> > The SIP Trunk as well as the CUE are in the same region supporting only
> > G.711. On the SIP Trunk I've tried all different kind of DTMF
> configurations
> > (No Preference, RFC 2833 and OOB). We've tried to force the GenBand SBC
> to
> > only use RFC 2833 as well as the SIP Trunk. But this didn't work, not
> even
> > after we added a MRGL with MTP's.
> >
> > Is there some sort of best practive to implement DTMF over a SIP Trunk?
> Is
> > there a way I can do some debugging on the CUCM/CUE?
> >
> > Kind regards,
> >
> > Paul van den IJssel
> > Digacom
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
> -----------------------------------------
> Disclaimer:
>
> This e-mail communication and any attachments may contain
> confidential and privileged information and is for use by the
> designated addressee(s) named above only.  If you are not the
> intended addressee, you are hereby notified that you have received
> this communication in error and that any use or reproduction of
> this email or its contents is strictly prohibited and may be
> unlawful.  If you have received this communication in error, please
> notify us immediately by replying to this message and deleting it
> from your computer. Thank you.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100715/1d871a2a/attachment.html>