[cisco-voip] SIP Trunk from ISP DTMF issue

Paul van den IJssel pijssel at gmail.com
Fri Jul 16 18:37:29 EDT 2010 

Hi Ahmed,

Have you looked under 'System > Security Profile > SIP Trunk Security
Profile' ?

[image: SIP Trunk SP.JPG]

2010/7/16 Ahmed Abd EL-Rahman <Ahmed.Rahman at bmbgroup.com>

>  Dear Paul,
>
>                 Could you please clarify where exactly the “"Accept
> Unsolicited Notification" box of the SIP Trunk Profile” as I can’t find
> this option in the sip trunk page or in the Standard Sip Profile page.
>
> Please help as I’m suffering from the DTMF problem and I’m using CUCM
> 7.1(3) with a sip trunk to my VGW which communicates with the Provider
> through a sip trunk on the VGW.
>
>
>
> Best Regards
>
>
>
> *Ahmed Abd EL-Rahman***
>
>
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Paul van den IJssel
> *Sent:* Friday, July 16, 2010 11:09 AM
>
> *To:* cisco-voip at puck.nether.net"
>  *Subject:* Re: [cisco-voip] SIP Trunk from ISP DTMF issue
>
>
>
> We got it to work! I checked the "Accept Unsolicited Notification" box of
> the SIP Trunk Profile, and now DTMF is working fine on my in- and outbound
> calls.
>
>
>
> Now here's the next challange.. SIP Trunk is in a region running G.711. IP
> Phone A and B are using G.711, IP Phone C and D are using G.729. All devices
> have a MRGL containing both MTP (G.711) and CFB (G.711). Setting up a conf
> call to the G.711 phones is working fine. But when I try to setup a conf
> call to phone A and B, or A and C. The G.729 call gets terminated. It should
> use the CFB and MTP just as it whould with a normal H.323 or MGCP gateway
> connected, right?
>
>
>
> Paul
>
>
>
>
> 2010/7/15 Nick Matthews <matthnick at gmail.com>
>
> You really have to check the DTMF settings on every hop.  I thought
> there was a CUE involved also?
>
> If you're not seeing the 101 PT in the SDP in the 200 OK you need to
> check the INVITE to see what PT is being advertised, and if it's being
> advertised at all.
>
> SIP INFO and NOTIFY are not generally widely used.  I would work with
> getting 2833 to work first.
>
> -nick
>
>
> On Thu, Jul 15, 2010 at 4:58 AM, Paul van den IJssel <pijssel at gmail.com>
> wrote:
> > Hi all,
> >
> >
> >
> > Here is some aditional information from the ISP side. they are using a
> > Genband MSX release 4.3m6 and we have the following options for DTMF
> > transmission:
> >
> >
> >
> > SIP NOTIFY
> >
> > SIP INFO
> >
> > RFC2833 (payload type 101)
> >
> >
> >
> > When we send DTMF to the CCM with SIP NOTIFY we see a 403 Forbidden
> comming
> > back from the CCM.
> >
> >
> >
> > One other thing i noticed is that when we place a inbound call to the CCM
> > --> IVR (using RFC2833) the 200OK doesen't contain a media type 101
> > (rfc2833), and if i'm correct the CCM was configured for RFC2833 at that
> > point. If the SBC doesen't receive the correct media type in the 200OK it
> > assumes that there is no support for RFC2833 and it will fallback to
> inband
> > DTMF tones in the audio stream.
> >
> >
> >
> > Could this have something to do with the DTMF transmission between the
> CCM
> > and unity express? Is the DTMF transmitted in the siggnaling between the
> CCM
> > and the unity express? Or is it using RTP payload like RFC2833 does?
> >
> >
> >
> > Here also a brief description of our setup:
> >
> >
> >
> >
> >
> > [ISDN30/DMS100]--------------------[Cisco AS5850]------------------[SIP
> > proxy]--------------------[Genband SBC]-----------------[CCM]
> >
> >                                ISDN30
> > SIP                            SIP
> SIP
> >
> >
> >
> >
> >
> > Thanks in advance,
> >
> >
> >
> > Jan Hazenberg
> >
> >
> >
> > 2010/7/15 Nicholas Samios <nsamios at staff.iinet.net.au>
> >>
> >> What codec are you using ?  i.e. Region settings, etc.
> >>
> >>
> >>
> >> >> 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).
> >>
> >>
> >>
> >> That’s incorrect.  CUCM’s inbuilt MTPs can be used to convert DTMF i.e.
> >> take OOB H245 and make it RFC2833, etc.
> >>
> >>
> >>
> http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/6x/media.html#wp1054848
> >>
> >>
> >>
> >> From: cisco-voip-bounces at puck.nether.net
> >> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Paul van den
> IJssel
> >> Sent: Thursday, July 15, 2010 4:21 PM
> >> To: cisco-voip at puck.nether.net
> >> Subject: Re: [cisco-voip] SIP Trunk from ISP DTMF issue
> >>
> >>
> >>
> >> 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.
> >>
> >>
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100717/02e591aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 59588 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100717/02e591aa/attachment.jpe>

More information about the cisco-voip mailing list