[Home]

Summary:ASTERISK-10990: [patch] During call setup signalling asterisk does not offer telephone-event (rfc2833) anymore
Reporter:Andy Brodmann (macbrody)Labels:
Date Opened:2007-12-07 07:36:01.000-0600Date Closed:2011-06-07 14:00:39
Priority:BlockerRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) diff-main_rtp.c
( 1) diff-main_rtp.c-against-svn_asterisk_trunk.txt
( 2) extension.conf
( 3) patch-channels-chan-sip-1.4.15.txt
( 4) sip.conf
( 5) sip-debug-trace.txt
( 6) working-sip-debug-trace-asterisk_1.4.13.txt
Description:What happened:
As of asterisk-1.4.15 (tested trunk too) asterisk, when
connected to a peer via sip trunk does not recognize dtmf
anymore (same config worked with 1.4.13).

What I found:
During signalling negotiation at call setup in the sdp body,
asterisk does not offer the rtpmap: telephone-event anymore,
even if I configure dtmfmode=rfc2833.

Therefore the other end will not send any rfc2833 specific rtp events.


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

I have tested it with 1.4.15 and with trunk.

Both do the same.

I have tested the situation on three identical machines with
exactly the same config using:

asterisk-1.4.13 (works fine)

asterisk-1.4.15 (no dtmf recog.)
asterisk-trunk (no dtmf recog.)
Comments:By: Russell Bryant (russell) 2007-12-07 09:30:15.000-0600

Please supply the relevant SIP debug trace, sip.conf entry, and extensions.conf section that is being executed when this problem occurs.
By: Andy Brodmann (macbrody) 2007-12-07 10:15:24.000-0600

sorry for forgetting the files.
I've uploaded them now.

The config has been like this since asterisk-1.4.3
and has been working upto 1.4.13. 1.4.15 was the first release
that does not work. I have not tested 1.4.14.
By: Andy Brodmann (macbrody) 2007-12-08 10:19:53.000-0600

Maybe my description was not so clear/misleading:

RFC2833 RTP DTMF support on SIP Trunks in asterisk-1.4.15
is broken!
By: Eliel Sardanons (eliel) 2007-12-08 12:14:52.000-0600

Could you upload the SIP debug trace of 1.4.13 in the same scenario that you say is working fine?
What I see here is that the Cisco is not doing the INVITE with the RFC2833 capability:
[Dec  7 16:54:05] VERBOSE[7209] logger.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)

Thanks
By: Andy Brodmann (macbrody) 2007-12-09 05:01:49.000-0600

Eliel,

working sip trace is uploaded as requested, thanks for your quick response btw.

In the working trace and the non working trace the sdp in the invite is the same, but asterisk-1.4.13 and asterisk-1.4.15 seem to interpret it differently.

> [Dec  9 11:41:41] VERBOSE[23938] logger.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1 (telephone-event), combined - 0x1 (telephone-event)

What may be the reason: Cisco does not use the telephony-event in the sdp but their X-NSE events. So asterisk-1.4.13 and earlier seem to accept/understand the
X-NSE events while asterisk-1.4.15 seems to ignore it.

Was it accidentally dropped? Or was it a particular reason? I have found a long closed issue where the handling of X-NSE was disscussed in 2004: The issue # is 3041.
By: Eliel Sardanons (eliel) 2007-12-09 20:41:37.000-0600

I think we never recognized X-NSE, we now see the "error" message because we are checking the return value of the setter function. Other thing was changed that make us loose compatibility.
By: Joshua C. Colp (jcolp) 2007-12-10 09:58:40.000-0600

Yes, the old stuff was broken. RFC2833 was never in the INVITE to begin with, it was something else with the same payload but the code mistakenly thought it was RFC2833 and happily negotiated it. While the old stuff actually worked in your scenario, it was the fact it was broken that made it work.
By: Andy Brodmann (macbrody) 2007-12-10 12:21:44.000-0600

file, eliel,

I see your point. As it is not an internal issue, but the connection to the only big provider (cablecom) in switzerland officially supporting asterisk, would one of the following scenarios be acceptable to digium?

1) a patch for forcing asterisk to send and use the telephone-event even if the other side does not send it (backward compatibility).
2) supporting an implementation for cisco x-nse.

I do see that x-nse as cisco's proprietary solution may not seem too attractive. Unfortunately just about all carriers/providers use cisco equipment.

What do you suggest?
By: Andy Brodmann (macbrody) 2007-12-10 15:06:52.000-0600

the following patch against: channels/chan_sip.c
will force the use of rfc2833 if rfc2833 is configured in sip.conf:

5357c5357,5361
<
---
>
>       /* If we locally define rfc2833, then force the use of rfc2833 */
>       if ((p->noncodeccapability & AST_RTP_DTMF) == AST_RTP_DTMF) {
>               newnoncodeccapability |= AST_RTP_DTMF;
>       }

Please consider this patch. This would allow for asterisk-1.4.15 and later to continue to be compatible to cisco equipment when using sip trunks.


By: Joshua C. Colp (jcolp) 2007-12-10 15:10:33.000-0600

All patches must be attached and have a proper license agreement before we can look at them.
By: Andy Brodmann (macbrody) 2007-12-10 15:46:41.000-0600

patch is uploaded and license is granted by your legal department.


By: Andy Brodmann (macbrody) 2007-12-11 10:59:23.000-0600

Hi,

I just saw the issue is still on status feedback.

Do you need more info from me concerning the patch?
By: Joshua C. Colp (jcolp) 2007-12-11 13:22:32.000-0600

I'm hesitant to go down this road because the previous issue filed previously was that Asterisk offered/used RFC2833 even when the other side didn't, which was a bug. Now we have a bug that is the opposite, that Asterisk should force it even if it wasn't negotiated. I'm hesitant to do that as I agree with the first issue.
By: Andy Brodmann (macbrody) 2007-12-12 02:00:46.000-0600

file,

I understand that. Let's consider the situation as is:

we fixed a bug but thereby broke rfc2833 interoperability with cisco equipment.
Currently (1.4.15+) only inband dtmf is possible with cisco equipment -> which is not usable in large environments.

Would one of the following options be acceptable?

1) A config option for manually setting/forcing the usage of rfc2833 wheter the
  other side offers it or not.
2) Accepting the X-NSE parameter as equal to the telephone-event parameter.

In asterisk-1.4.15+ the option dtmfmode=rfc2833 could be deprecated anyway as it is no longer used if I understand that correctly. Instead dtmfmode=auto does the same job.

To keep rfc2833 interoperability to cisco equipment what way do you suggest
is acceptable?
By: Eliel Sardanons (eliel) 2007-12-12 09:46:56.000-0600

dtmfmode=rfc2833 is checked against endpoint capabilities, so if endpoint tries to use rfc2833 and we only accept sip info (bacause it is setted on the .conf), there will be no agreement in the negotiation, that is the use we give to dtmfmode, not to force the negotiation just to accept what the endpoint has to offer.

I think we already support cisco incompatibilities so (or at least I have seen if (cisco) {} code), the best way would be to support X-NSE, but this should be discussed on the mailing list.
By: Andy Brodmann (macbrody) 2007-12-12 09:50:40.000-0600

Eliel,

so how do we proceed with this issue?
By: Eliel Sardanons (eliel) 2007-12-12 11:48:34.000-0600

Send an email to asterisk-dev mailing list referencing this issue to start discussing this issue.

Thanks
By: Andy Brodmann (macbrody) 2007-12-20 09:14:21.000-0600

Uploaded the patch: diff-main_rtp.c

As discussed on asterisk-dev this will tell asterisk
to accept the sdp option 'X-NSE' to be equal to 'telephone-event'.

X-NSE is used by cisco as a supplement to rfc2833. So if this occurs
we can assume that the cisco device on the other side uses rfc2833
even if they don't indicate it with telephone-event.

In fact when the other side sends 'X-NSE' they signal that they understand
more than just the basic subset of rfc2833.
By: Eliel Sardanons (eliel) 2007-12-20 09:19:42.000-0600

macbrody: Please upload this patch according to bug-guidelines (a diff against SVN trunk).

Thanks!
By: Andy Brodmann (macbrody) 2007-12-20 09:43:46.000-0600

ok, checked out /svn/asterisk/trunk, made the changes
and then 'svn diff'.

If you need it against /svn/asterisk/branch/1.4
please let me know.
By: Alexander Tull (alex-911) 2008-01-07 05:31:39.000-0600

this issue could be solved by an appropriate configuration on the cisco media gateways. when the gateway sends "a=rtpmap:99 telephone-event/8000", DTMF is recognized. I have tested this against 1.4.17.
@macbrody: pls test against your provider. it should work now ;)
By: Andy Brodmann (macbrody) 2008-01-10 04:51:30.000-0600

file,eliel,

please close this issue. alex-911 (our carrier guy) has altered the config on his side (the cisco gateways).

It may still be useful to keep this for the support records, in case other people stumble over the same issue (not every carrier is willing to adapt his systems for a single customer).

So the attached patch may come in handy in case someone needs an urgent work around (we've been running our system with it for a month now).

-macbrody
By: Michiel van Baak (mvanbaak) 2008-01-10 05:06:35.000-0600

Closed on reporters request.