| 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 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Codecs/General |
| Versions: | 1.8.6.0 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Not Relevant | Attachments: | |
| Description: | Call is incoming to Asterisk through SIP. The INVITE from the other party tells: m=audio 2002 RTP/AVP 18 101 a=fmtp:101 0-15 Asterisk answers with a OK, with session description, but containing: m=audio 18734 RTP/AVP 18 101 a=fmtp:101 0-16 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 [7]). The payload formats use the following fmtp format to list the event values that they can receive: | ||