Summary:ASTERISK-17765: Can't provide secure audio requested in SDP offer
Reporter:Stefan Baldus (stefanero)Labels:
Date Opened:2011-04-28 08:29:40Date Closed:2011-06-07 14:01:01
Versions:1.8.3 Frequency of
Environment:Attachments:( 0) sip-trace-not-ok.txt

I am running * version 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 * 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.


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:

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: = asterisk = CS1KE - core = Nortel SigSRV = 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


well thing is, we use the same Nortel Gateway with asterisk and its working fine.

There is no srtp support in
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

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

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:


the issue is here:


Please give me a feedback if you decide to try our patch. (Note: Before the test please unload Asterisk SRTP module)