[Home]

Summary:ASTERISK-06388: Asterisk 1.2.4 fails to send request for RFC2833
Reporter:edgreenberg (edgreenberg)Labels:
Date Opened:2006-02-21 18:35:42.000-0600Date Closed:2011-06-07 14:10:43
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/CodecHandling
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20050427.txt
( 1) chan_sip.c.diff
( 2) sipshowchannel.txt
( 3) siptrace.txt
Description:I have dtmfmode=RFC2833 in my sip.conf, but Asterisk does not request it of the user (on an incoming call.)

In the SDP message, I would expect to see a 101 on the end of the m= line as well an a= line.

SIP trace attached.

****** ADDITIONAL INFORMATION ******

My sip.conf line:
[level3a]
type=friend
host=xx.xx.xx.xx
insecure=very
context=level3inbound
disallow=all
allow=ulaw
dtmfmode=rfc2833
Comments:By: edgreenberg (edgreenberg) 2006-02-23 12:07:21.000-0600

Adding the output of sip show channel level3a. It really does think it's RFC2833.


 * Name       : level3a
 Secret       : <Not set>
 MD5Secret    : <Not set>
 Context      : level3inbound
 Subscr.Cont. : <Not set>
 Language     :
 AMA flags    : Unknown
 CallingPres  : Presentation Allowed, Not Screened
 Callgroup    :
 Pickupgroup  :
 Mailbox      :
 VM Extension : asterisk
 LastMsgsSent : -1
 Call limit   : 0
 Dynamic      : No
 Callerid     : "" <>
 Expire       : -1
 Insecure     : port,invite
 Nat          : RFC3581
 ACL          : No
 CanReinvite  : Yes
 PromiscRedir : No
 User=Phone   : No
 Trust RPID   : No
 Send RPID    : No
 DTMFmode     : rfc2833
 LastMsg      : 0
 ToHost       : 4.68.251.13
 Addr->IP     : 4.68.251.13 Port 5060
 Defaddr->IP  : 0.0.0.0 Port 0
 Def. Username:
 SIP Options  : (none)
 Codecs       : 0x4 (ulaw)
 Codec Order  : (ulaw)
 Status       : Unmonitored
 Useragent    :
 Reg. Contact :
By: Andrey S Pankov (casper) 2006-02-23 17:07:26.000-0600

Your output is from 'show peer level3a'. If you look at the output of 'show channel ...' whilst in an active call you'll see "DTMF Mode: inband", right?
By: Andrey S Pankov (casper) 2006-02-23 17:08:25.000-0600

I meant 'sip show' of course... ;)
By: edgreenberg (edgreenberg) 2006-02-24 10:27:40.000-0600

I show RFC2833 in the sip show channel output.  See sipshowchannel.txt.
By: Andrey S Pankov (casper) 2006-02-24 15:01:20.000-0600

Please try chan_sip.c.diff
By: edgreenberg (edgreenberg) 2006-02-24 18:38:32.000-0600

This resolved the problem perfectly.
By: Joshua C. Colp (jcolp) 2006-02-27 13:10:04.000-0600

Let me give you a run through of why this patch doesn't sit well with me and what the issue was.

Level3 was not advertising RFC2833 in the initial INVITE, so when chan_sip did a negotiation of non codecs (ie: RFC2833) it did not find RFC2833 as being common between the two. This patch completely removes non codec negotiation, and has chan_sip always using what is specified for non codec capabilities - potentially not a good thing.

What about having a separate option that a person explicitly sets to not do non codec negotiation? That would be more reasonable then removing negotiation for every session.
By: edgreenberg (edgreenberg) 2006-02-28 02:52:04.000-0600

When Level 3 invited me to the call, their SDP packet did not specify out of band DTMF. They said:
m=audio 60002  RTP.AVP 0 18

Since they invited, should they not have offered out-of-band DTMF by stating:
m=audio 60002  RTP.AVP 0 18 101

I suspect that had they done so, we would have responded in kind.

A quick scan of the RFC for SDP does not indicate whether the response should be limited to those capabilities that intersect with the senders capabilities or whether they should indicate the entire set of available capabilities. Can anybody point me to a standard that clarifies this, so I can discuss it with Level 3?
By: Joshua C. Colp (jcolp) 2006-02-28 09:20:25.000-0600

According to RFC 3264 (An Offer/Answer Model Session Description Protocol):

The stream MAY indicate additional media formats, not listed in the
corresponding stream in the offer, that the answerer is willing to
send or receive (of course, it will not be able to send them at this
time, since it was not listed in the offer).

So we can offer it back, but I still don't like the idea of completely removing non codec negotiation to do it since the above could also apply to audio codecs. Making it an option would be better.
By: edgreenberg (edgreenberg) 2006-02-28 09:29:46.000-0600

What about the idea that we 'and' the offered codecs into the response, and then unconditionally 'and' in the bit for RFC2833, since the fellow who wrote the sip.conf said we would accept it even if we didn't get it in the INVITE.

Other non-codec capabilities (are there any?) might be similarly discussed, to see if it makes sense to ask for them as well.
By: Joshua C. Colp (jcolp) 2006-02-28 09:39:15.000-0600

If the codec is set to be rfc2833, and option is set to offer it regardless - yes that would be fine with me. Anyone else have anything to say?
By: edgreenberg (edgreenberg) 2006-02-28 09:41:03.000-0600

One more interesting thing...

Back in 4/2005, under Asterisk 1.0.5, I captured a session that has this same situation, where level3 did not send 101 but we responded with it.

See packets 1 and 3 in file 20050427.txt

So was this a conscious change?

</edg>
By: Joshua C. Colp (jcolp) 2006-02-28 09:48:04.000-0600

That was a long time ago and many revisions ago... so much that I wiped it out of my mind. There was probably some reason it was changed though, or it may have been a cascade effect from some other change.
By: Olle Johansson (oej) 2006-03-10 06:42:13.000-0600

Ok. The summary is that this is not a bug, but more of a feature request. The patch was not disclaimed, nor approved.

If you produce a patch that solves the problem according to this discussion, we will re-open and look at that and see if that fits our requirements.

Always remember to mention that you have a disclaimer when adding patches. Thanks.