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-0600 | Date Closed: | 2011-06-07 14:10:43 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | 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. |