RE: [Asterisk-Dev] NO DTMF in the Outgoing call

[Chris Heiser]

Areski,

I have had similar problems especially when attempting to send DTMF to a
Cisco ATA186 attached to a PBX.  Attached is a patch for rtp.c to increase
the duration of RFC2833 DTMF tones to a more reasonable value.  Try it out
and see what happens!

--Chris

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:asterisk-dev-
> [EMAIL PROTECTED] On Behalf Of Areski
> Sent: Wednesday, February 11, 2004 10:50 AM
> To: asterisk-dev
> Subject: [Asterisk-Dev] NO DTMF in the Outgoing call
> 
> Hello all,
> 
> I cannot have DTMF working when I m making an outgoing call from Asterisk.
> I tried on different servers with different  Asterisk versions.
> I tested all configurations possible with X-lites and also with a
> CiscoAS5300,
> no way... always the same problem.
> 
> I was trying to do some modifications in chan_sip but I m pretty novice
> with Asterisk sources and I didn't find out anything.
> After scanning the sip log, I m thinking it's perhaps an RTP problem.
> Below, I attached the sip log...
> 
> I will greatly appreciate if someone can give me some advices.
> Kind regards,
> Areski
> 
> 
> 
> - SIP DEBUG OUTGOING-CALL : ASTERISK -> X-LITE --
> 
> 
> We're at 192.168.1.252 port 16642
> Answering with preferred capability 8
> Answering with non-codec capability 1
> 12 headers, 9 lines
> Reliably Transmitting:
> INVITE sip:[EMAIL PROTECTED] SIP/2.0
> Via: SIP/2.0/UDP 192.168.1.252:5060;branch=z9hG4bK708ccbe6
> From: "asterisk" ;tag=as3c490458
> To: 
> Contact: 
> Call-ID: [EMAIL PROTECTED]
> CSeq: 102 INVITE
> User-Agent: Asterisk PBX
> Date: Wed, 11 Feb 2004 15:42:36 GMT
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER
> Content-Type: application/sdp
> Content-Length: 191
> 
> v=0
> o=root 11215 11215 IN IP4 192.168.1.252
> s=session
> c=IN IP4 192.168.1.252
> t=0 0
> m=audio 16642 RTP/AVP 8 101
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
>  (no NAT) to 192.168.1.29:5060
> 
> 
> Sip read:
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 192.168.1.252:5060;branch=z9hG4bK708ccbe6
> From: "asterisk" ;tag=as3c490458
> To: ;tag=as3c490458
> Contact: 
> Call-ID: [EMAIL PROTECTED]
> CSeq: 102 INVITE
> User-Agent: X-Lite build 1079
> Content-Length: 0
> 
> 
> Sip read:
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP 192.168.1.252:5060;branch=z9hG4bK708ccbe6
> From: "asterisk" ;tag=as3c490458
> To: ;tag=as3c490458
> Contact: 
> Call-ID: [EMAIL PROTECTED]
> CSeq: 102 INVITE
> User-Agent: X-Lite build 1079
> Content-Length: 0
> 
> 
> Sip read:
> SIP/2.0 200 Ok
> Via: SIP/2.0/UDP 192.168.1.252:5060;branch=z9hG4bK708ccbe6
> From: "asterisk" ;tag=as3c490458
> To: ;tag=as3c490458
> Contact: 
> Call-ID: [EMAIL PROTECTED]
> CSeq: 102 INVITE
> Content-Type: application/sdp
> User-Agent: X-Lite build 1079
> Content-Length: 197
> 
> v=0
> o=phone1 161667652 161667652 IN IP4 192.168.1.29
> s=X-Lite
> c=IN IP4 192.168.1.29
> t=0 0
> m=audio 8000 RTP/AVP 8 101
> a=rtpmap:8 pcma/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> 
> 10 headers, 9 lines
> Found audio format ALAW
> Found audio format UNKN
> Found description format pcma
> Found description format telephone-event
> Capabilities: us - 8, them - 8/0, combined - 8
> Non-codec capabilities: us - 1, them - 1, combined - 1
> list_route: hop: 
> set_destination: Parsing  for address/port
> to send to
> set_destination: set destination to 192.168.1.29, port 5060
> Transmitting:
> ACK sip:[EMAIL PROTECTED]:5060 SIP/2.0
> Via: SIP/2.0/UDP 192.168.1.252:5060;branch=z9hG4bK708ccbe6
> From: "asterisk" ;tag=as3c490458
> To: ;tag=as3c490458
> Contact: 
> Call-ID: [EMAIL PROTECTED]
> CSeq: 102 ACK
> User-Agent: Asterisk PBX
> Content-Length: 0
> 
>  (no NAT) to 192.168.1.29:5060
> 
> 
> 
> ___
> Asterisk-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
> 



rtp.c.patch
Description: Binary data

RE: [Asterisk-Dev] FW: Payload numbers (X-Lite to Asterisk codec problem)

[Chris Heiser]

Rob,

Give this a shot:

Index: chan_sip.c
===
RCS file: /usr/cvsroot/asterisk/channels/chan_sip.c,v
retrieving revision 1.170
diff -u -r1.170 chan_sip.c
--- chan_sip.c  25 Aug 2003 14:17:14 -  1.170
+++ chan_sip.c  26 Aug 2003 14:32:50 -
@@ -119,7 +119,7 @@
 static int restart_monitor(void);

 /* Codecs that we support by default: */
-static int capability = AST_FORMAT_ULAW | AST_FORMAT_ALAW | AST_FORMAT_GSM
| AST_FORMAT_H263;
+static int capability = AST_FORMAT_ULAW | AST_FORMAT_ALAW | AST_FORMAT_GSM
| AST_FORMAT_H263 | AST_FORMAT_ILBC;
 static int noncodeccapability = AST_RTP_DTMF;

 static char ourhost[256];


--Chris

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:asterisk-dev-
> [EMAIL PROTECTED] On Behalf Of Rob
> Sent: Monday, August 25, 2003 11:12 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Asterisk-Dev] FW: Payload numbers (X-Lite to Asterisk codec
> problem)
> 
> 
> If a developer knowledgeable about the SDP/RTP payload code would like to
> test with a developer from XTen to fix the speex/iLBC problem, I'd be
> happy
> to set that up. Let me know.
> 
> -Rob
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Peter Grace
> Sent: August 22, 2003 4:58 PM
> To: [EMAIL PROTECTED]
> Subject: [Asterisk-Dev] FW: Payload numbers (X-Lite to Asterisk codec
> problem)
> 
> 
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Anyone know how to make sense of this?  I'm pretty dumb
> when it comes to the rtp protocol.  If someone can confirm
> this is a bug, we can put it into bugs.digium.com...
> 
> Pete
> 
> - -Original Message-
> From: Robin Raymond [mailto:[EMAIL PROTECTED]
> Sent: Friday, August 22, 2003 6:48 PM
> To: Peter Grace
> Subject: RE: Payload numbers
> 
> 
> 
> Hi Peter,
> 
> Well, from what I understand by this user, Asterisk is not
> examining the RTP payload number for speex or iLBC that
> X-Lite is using.
> 
> In the INVITE request, I tell Asterisk which codec payload
> numbers I'm using, which is different that what Asterisk
> sends back. Asterisk reports back it's payload numbers. I
> send my RTP using your speex/iLBC payload numbers that you
> expect from your SDP, and I expect RTP to come back with my
> speex/iLBC payload numbers that I provided in my SDP. Now
> I'm not 100% sure I'm doing that right, so perhaps I have a
> bug.
> 
> v=0
> o=21186 21339250 21339250 IN IP4 64.180.128.147
> s=X-PRO
> c=IN IP4 64.180.128.147
> t=0 0
> m=audio 8000 RTP/AVP 0 8 3 98 97 101
> a=rtpmap:0 pcmu/8000
> a=rtpmap:8 pcma/8000
> a=rtpmap:3 gsm/8000
> a=rtpmap:98 iLBC/8000 <-- this is my mapping
> a=rtpmap:97 speex/8000 <-- this is my mapping
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> 
> As what I understand, calling w/ speex/iLBC simply doesn't
> work between X-Lite and Asterisk. Not sure why.
> 
> No I didn't receive the e-mail about the PPC. Feel free to
> CC me on stuff like that :)
> 
> Any ideas?
> 
> - -Rob
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: PGPfreeware 7.0.3 for non-commercial use 
> 
> iQA/AwUBP0at7NW8rcEEsO4aEQLKpwCeOBIZ3pogL2JQ6EL9p50EBW/PYZ8An063
> ereE1and4UKs7/uFcF45iu0M
> =r3uu
> -END PGP SIGNATURE-
> 
> 
> 
> ___
> Asterisk-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.digium.com/mailman/listinfo/asterisk-dev
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Bug 14 in bug tracker (fwd)

[Chris Heiser]

Mark,

FYI...

X-ten has e-mailed me and are working to resolve this odd implementation in
X-lite (I presume they'll check X-pro) so that it follows the RFC.  This is
the first DTMF problem I've come across where the duration field was the
problem.  Most issues I've seen have to do with the Sip endpoint ignoring
the SDP info from Asterisk.

--Chris Heiser

- Original Message -
From: "Mark Spencer" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, July 25, 2003 1:57 PM
Subject: RE: [Asterisk-Dev] Bug 14 in bug tracker (fwd)


> It's a little of both probably.  Asterisk's handling of DTMF in RTP isn't
> proper either -- it is made around an attempt to be robust in handling
> good implementations, but that makes it sensitive to odd implementations.
>
> Mark
>
> On Fri, 25 Jul 2003, Peter Grace wrote:
>
> > I've done a workaround in rtp.c, but I know I'd prefer for the
> > solution to be concrete.  What exactly is wrong, so we can give the
> > xten people a good idea of what needs to be done?  From your message I
> > gather that the duration field is not being properly populated?
> >
> > On Fri, 25 Jul 2003, Chris Heiser wrote:
> >
> > > This actually appears to be a bug with the X-Lite Sip Phone.
> > > I've done some packet captures, and the X-Lite violates RFC2833.
> > >
> > > For the Payload of the RTP packet for DTMF, the RFC states:
> > >
> > > "   duration: Duration of this digit, in timestamp units. Thus, the
> > >event began at the instant identified by the RTP timestamp
> > >and has so far lasted as long as indicated by this
parameter.
> > >The event may or may not have ended."
> > >
> > > X-Lite never increments the duration field of the RTP packets for DTMF
> > > digits.  I'm sure this is confusing Asterisk.  I'd say e-mail the
X-Lite
> > > folks and tell them they have bugs.
> > >
> > > --Chris Heiser
> > >
> > > > -Original Message-
> > > > From: [EMAIL PROTECTED] [mailto:asterisk-dev-
> > > > [EMAIL PROTECTED] On Behalf Of Chris Heiser
> > > > Sent: Thursday, July 24, 2003 6:47 PM
> > > > To: [EMAIL PROTECTED]
> > > > Subject: Re: [Asterisk-Dev] Bug 14 in bug tracker (fwd)
> > > >
> > > > Peter,
> > > >
> > > > Can you send a tcpdump of the session between asterisk and the
X-lite
> > > > phone?
> > > >
> > > > Something like: tcpdump -s 0 -w xlite-phone-dump host [x-lite ip
address]
> > > > Make sure you run it while you're not logged in or otherwise
connected to
> > > > Asterisk (so the tcpdump only has the packets between the X-lite
phone and
> > > > Asterisk)
> > > >
> > > > I'd say just e-mail it to me direct as the file will probably be a
little
> > > > big to go out on the mailing list.
> > > > I've had to debug other DTMF issues with other devices.  (I've come
across
> > > > a
> > > > few sip UA's that ignore the SDP info that Asterisk sends out).
Maybe I
> > > > can
> > > > be of some help.
> > > >
> > > > --Chris Heiser
> > > >
> > > > - Original Message -
> > > > From: "Peter Grace" <[EMAIL PROTECTED]>
> > > > To: <[EMAIL PROTECTED]>
> > > > Sent: Thursday, July 24, 2003 3:54 PM
> > > > Subject: [Asterisk-Dev] Bug 14 in bug tracker (fwd)
> > > >
> > > >
> > > > > Oops.  Helps if you have the list address right.. See below!
> > > > >
> > > > > -- Forwarded message --
> > > > > Date: Thu, 24 Jul 2003 15:04:44 -0400 (EDT)
> > > > > From: Peter Grace <[EMAIL PROTECTED]>
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Bug 14 in bug tracker
> > > > >
> > > > > Guys,
> > > > >
> > > > > I just fired in a bug report, but I'll give the rundown:
> > > > >
> > > > > http://bugs.digium.com/bug_view_page.php?bug_id=014
> > > > >
> > > > >
> > > > > X-Lite's DTMF problems with voicemail may not be X-lite's fault...
I
> > > > was
> > > > > tracking DTMF between rtp.c and channel.c and it looks like the
system
> > > > is
> > > > > ign