| Summary: | ASTERISK-08712: need more 'relaxed' DTMF INFO handling to interop with TI-based SIP-adapters | ||
| Reporter: | AndrewZ (andrewz) | Labels: | |
| Date Opened: | 2007-02-01 09:04:26.000-0600 | Date Closed: | 2011-06-07 14:03:20 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/Interoperability |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) Asterisk_info_debug.TXT ( 1) info_decoded.txt | |
| Description: | Some SIP-adapters like Linksys PAP2 ver.2, Linksys WRTP54G, Linksys WAG54GP2, Linksys RTP300, Vtech IP8100, Motorola VT2442, D-Link VTA-VR which are based on TI AR7 chipset are sending DTMF INFO packets in a manner which is different from the other devices are using. As a result they are not recognized by Asterisk. ---------------- Ethereal decode for DTMF digit '1' (good example): Message body Signal=1\r\n Duration=100\r\n --------------- Ethereal decode for DTMF digit '1' (bad example): Message body Signal=1\r Duration=70\r Asterisk output: Signal=1 Duration=70 <-------------> --- (13 headers 0 lines) --- Receiving INFO! [Jan 31 18:32:22] WARNING[20818]: chan_sip.c:11002 handle_request_info: Unable to parse INFO message from 101997b0-2105a8c0-2710-45c0b65f-2d6b755a-45c0b65f@butthead.lan. Content <--- Transmitting (no NAT) to 192.168.5.33:10000 ---> SIP/2.0 415 Unsupported media type --------------- In the bad example only CR symbol is present and LF is missing, so Asterisk reports 415 Unsupported media type according to rfc2976: "If the INFO request contains a body that the server does not understand then, in the absence of INFO associated processing rules for the body, the server MUST respond with a 415 Unsupported". Media Type message. | ||
| Comments: | By: Olle Johansson (oej) 2007-02-01 10:59:51.000-0600 If you read the bug guidelines, you understand that you need to add a full SIP debug output so we can see the context of the INFO and the full SIP message. Re-read the guidelines and upload that file, thank you! Should be easy to fix as long as we see what's going on in full. By: Olle Johansson (oej) 2007-02-01 11:02:07.000-0600 From the error message, something seems wrong in the content-type definition in the headers, which we don't see in this bug report. By: AndrewZ (andrewz) 2007-02-01 11:16:24.000-0600 Right, my fault. I'm uploading the Ethereal trace and will add Asterisk debug in a few minutes. From what I see content-type is wrong as well. By: AndrewZ (andrewz) 2007-02-01 11:40:31.000-0600 0008963 & 0008964 are not duplicates! rfc2833 and INFO problems are different - In first case the 'end' packet is missing, in the 2nd - packet format is incorrect. Thank you. By: Olle Johansson (oej) 2007-02-01 15:24:35.000-0600 You need to have SIP DEBUG turned on so we see all packets. THanks. By: Olle Johansson (oej) 2007-02-01 15:25:50.000-0600 You must have buggy firmware. Content-Type: application/text Doesn't follow any specs at all. I don't see the payload, since you did not turn on SIP debug, but this seems to be a failure on the device side, not Asterisk side. By: AndrewZ (andrewz) 2007-02-01 15:37:00.000-0600 Of course it's a firmware problem, I agree. That's why I used the term "feature" instead of "bug". It will be nice to have a feature to overcome this firmware problem. I don't think we can force all the vendors I mentioned at the begining to fix the code. Most of those devices are sold locked to Vonage and other providers. As soon as they are quite cheap people are buying them and get them unlocked. By: Olle Johansson (oej) 2007-02-02 09:32:57.000-0600 Then move to another DTMF setting in the devices... I can't assume that there's stuff I need for DTMF in a message with that attachment type. | ||