|Summary:||ASTERISK-18755: SDP DTMF negotiation issue: fmtp:101 0-16|
|Reporter:||Laurent Debacker (ldebacker)||Labels:|
|Date Opened:||2011-10-26 03:24:02||Date Closed:||2011-11-07 11:09:09.000-0600|
|Description:||Call is incoming to Asterisk through SIP.|
The INVITE from the other party tells:
m=audio 2002 RTP/AVP 18 101
Asterisk answers with a OK, with session description, but containing:
m=audio 18734 RTP/AVP 18 101
This causes an issue, as Asterisk responds with a capability (flash hook) that is known to be unsupported on the other side.
As a result, A new invite is sent by the remote switch, and outband DTMF (RFC2833) is impossible.
|Comments:||By: David Woolley (davidw) 2011-10-26 07:08:18.621-0500|
The other side is broken. For this part of the negotiation, both sides send their actual capabilities. If the other side is not actually capable of sending Flash, it should simply not send it.
As the other side has said that is not capable, Asterisk should not send it Flash.
Although it may be unusual, it is perfectly legal for completely different codecs to be negotiated in the two directions.
The actual codecs used are specified in the RTP stream, at the time they are used.
Receivers MAY indicate which named events they can handle, for
example, by using the Session Description Protocol (RFC 2327 ).
The payload formats use the following fmtp format to list the event
values that they can receive: