Summary: | ASTERISK-17765: Can't provide secure audio requested in SDP offer | ||
Reporter: | Stefan Baldus (stefanero) | Labels: | |
Date Opened: | 2011-04-28 08:29:40 | Date Closed: | 2011-06-07 14:01:01 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/SRTP |
Versions: | 1.8.3 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Attachments: | ( 0) sip-trace-not-ok.txt | |
Description: | Hello, I am running * version 1.8.3.2 on opensuse 11.3 x86_64 we have a lot of Voice over WLan phones attached to our * , which use * as a generic gateway to our Nortel CS1KE (rel 5.5). I wanted to upgrade from * 1.6.0.24 to latest 1.8.X version. when now calling from SIP phone to Nortel everything is okey, all calls work no problem. but when I want to transfer an existing wlan-nortel call to a 2nd nortel phone I get an error in the asterisk console. also the RTP stream is dead on both ends, and noone can hear the other. ****** ADDITIONAL INFORMATION ****** I compiled the * with srtp support, just as a test but this did not work aswell. I tryed in modules.conf unload res_srdp and also my sip.conf contains: encryption=no all did not help. I dont want to use SRTP, it is just not getting disabled. If you need any more informations let me know. IPs in the attached log: 10.0.2.22 = asterisk 1.8.3.2 10.0.2.200 = CS1KE - core 10.0.2.133 = Nortel SigSRV 10.251.18.235 = Unidata SIP phone | ||
Comments: | By: David Woolley (davidw) 2011-04-28 08:52:46 This appears to be a problem (not necessarily a bug) with the Nortel gateway. It is the one that is insisting on an encrypted audio path, and closing the connection when it is not accepted. I do not see an Asterisk bug here. By: Leif Madsen (lmadsen) 2011-04-28 08:57:24 Requesting feedback per davidw. By: Stefan Baldus (stefanero) 2011-04-28 09:25:41 Hi, well thing is, we use the same Nortel Gateway with asterisk 1.6.0.24 and its working fine. There is no srtp support in 1.6.0.24. The nortel might offer srtp to asterisk, but instead of trying to get a connection asterisk should just decline it and use RTP instead. By: David Woolley (davidw) 2011-04-28 09:43:55 RFC 4568 says If there are one or more crypto attributes in the offer, but none of them are valid or none of the valid ones are supported, the offered media stream MUST be rejected. The only alternative to rejecting the whole INVITE is to reject the stream, but that would leave a session with no media streams. The answerer cannot counter-bid. My guess is that Asterisk 1.6.x didn't understand SDP crypto, so fell back on this clause: 5.3. General Backwards Compatibility Considerations In the offer/answer model, it is possible that the answerer supports a given secure transport (e.g., "RTP/SAVP") and accepts the offered media stream, but that the answerer does not support the crypto attribute defined in this document and hence ignores it. The offerer can recognize this situation by seeing an accepted media stream in the answer that does not include a crypto line. In that case, the security negotiation defined here MUST fail. I'd assume that either the Nortel is broken and violating a MUST clause, or it does retry without encryption, in that case. By: Stefan Baldus (stefanero) 2011-04-28 09:55:59 Well can I prevent asterisk from offering crypto? apperently the Nortel supports both srtp and rtp, our current asterisk (1.6) does not offer srtp and therefor it gets ignored maybe? I do get a warning in 1.6 chan_sip.c:7183 process_sdp: Unsupported SDP media type in offer: audio 5216 RTP/SAVP 8 0 18 101 111 but here asterisk and nortel can communicate in the end fine. I am wondering how I can tweak 1.8 asterisk to behave like 1.6, or did 1.6 also behave wrong here?! thnx for the help stefanero By: David Woolley (davidw) 2011-04-28 10:00:25 Asterisk is not offering crypto! It is the Nortel that is offering crypto. Before Asterisk was probably ignoring crypto parameters in incoming requests, but now it knows when it can't handle them, so is actively refusing them. By: Stefan Baldus (stefanero) 2011-04-28 10:09:13 so solution would be a) try to disbale srtp on nortel b) get a srtp communication running with asterisk and nortel By: David Woolley (davidw) 2011-04-28 10:21:39 Those sound like the sensible short term actions - making an explicit policy of no encryption is better than relying on falling back to it. However, it might be instructive to know if the Nortel accepted the invalid response from 1.6,or retried without offering encryption. In the latter case, it might be worth investigating rejecting just the failed stream, rather than the whole INVITE. I'm not sure anyone would put time into investigating rejecting the stream unless there was some evidence that it might help on a significant number of peers, particularly given that your two options are probably better choices in most cases. By: Stefan Baldus (stefanero) 2011-05-02 00:44:48 Hello again, okey thank you very much for the help. I guess you can close this ticket then, we will try to find a solution with Nortel. Thnx again stefanero By: Pasquale d'Antuono (dantuono) 2012-05-03 12:09:48.379-0500 Hi Stefanero, this is exactly the same issue that i have experienced. The same is for the Nortel CS1KE rel 7.5. We have solved with this patch: https://issues.asterisk.org/jira/secure/attachment/40781/fallback_srtp.patch the issue is here: https://issues.asterisk.org/jira/browse/ASTERISK-18201 Please give me a feedback if you decide to try our patch. (Note: Before the test please unload Asterisk SRTP module) |