[Home]

Summary:ASTERISK-17845: [patch] Invite with session description that supports both SRTP(SAVP) and RTP(AVP) fails if asterisk is not configured to use SR
Reporter:Jacco van Tuijl (jacco)Labels:
Date Opened:2011-05-12 02:17:48Date Closed:2011-06-20 12:36:33
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/SRTP
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) invite_with_both_RTP_and_SRTP.pcap
( 1) issue19281_2.patch
( 2) issue19281.patch
Description:I was doing an interoperability with a HiPath 3000 V8 M5T SIP Stack/4.0.26.26 and it failed.

It has to do with an invite with session desription that supports both SRTP(SAVP) and RTP(AVP); when asterisk is not configured for SRTP it will not start an RTP session.
Asterisk CLI shows :
chan_sip.c: Can't provide secure audio requested in SDP offer
and does not continue with setting up rtp

I guess it should provide an insecure audio request en continue with RTP

tested in asterisk 1.8.2.4 and asterisk 1.8.4




****** ADDITIONAL INFORMATION ******

Information on the asterisk-dev mailing list per Kevin Fleming:

http://lists.digium.com/pipermail/asterisk-dev/2011-May/049167.html
Comments:By: Stefan Schmidt (schmidts) 2011-05-12 03:00:30

i am not sure if this could work but it makes sense to me, if the peer offers non secure AVP too and asterisk couldnt handle SAVP that we fall back to normal AVP.

By: Stefan Schmidt (schmidts) 2011-05-12 03:37:22

btw pcap isnt recommended for issues so i copy the invite in here:

v=0
o=MxSIP 0 1849763221 IN IP4 192.168.1.100
s=SIP Call
c=IN IP4 192.168.1.100
t=0 0
m=audio 29100 RTP/AVP 8 0 18 4 98 99
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 red/8000
a=silenceSupp:off - - - -
a=fmtp:4 annexa=no
a=fmtp:98 0-15
a=fmtp:99 98
a=sendrecv
m=audio 0 RTP/SAVP 8 0 18 4 98 99
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 red/8000
a=silenceSupp:off - - - -
a=fmtp:4 annexa=no
a=fmtp:98 0-15
a=fmtp:99 98
a=sendrecv

By: Stefan Schmidt (schmidts) 2011-05-12 03:57:53

my patch would solve another problem which is in this invite. the invite offers two simultan audio streams, one with normal RTP the other with SRTP but the second offer doesnt have a port number but a=sendrecv.

BTW asterisk couldnt support two streams of the same type like audio, only different streams like audio + video.

the RFC definition says this offer is valid only the port is not right, but normally asterisk should handle this right.

By: Leif Madsen (lmadsen) 2011-05-12 07:20:16

I have added a note from the asterisk-dev mailing list from Kevin Fleming about the media architecture. I wonder if we can do anything here about this, because as Kevin mentions, there is no mechanism to "fail over" to a non-secure stream. I may be that Asterisk is actually RFC compliant in this case.

By: Jacco van Tuijl (jacco) 2011-05-12 07:45:34

**** malformed patch at line 34:

By: Jacco van Tuijl (jacco) 2011-05-12 09:48:56

I've got a response back from siemens:
L.S.,

In my opinion, the SDP offered by the Hipath is correct according the RFC3264.

The offer will contain zero or more media streams (each media stream
  is described by an "m=" line and its associated attributes).  

A port number of zero in the offer indicates that the
  stream is offered but MUST NOT be used.  This has no useful semantics
  in an initial offer, but is allowed for reasons of completeness,
  since the answer can contain a zero port indicating a rejected stream

In all cases, the formats in the "m=" line MUST be listed in order of
  preference, with the first format listed being preferred.  In this
  case, preferred means that the recipient of the offer SHOULD use the
  format with the highest preference that is acceptable to it.

If multiple media streams of different types are present, it means
  that the offerer wishes to use those streams at the same time.  A
  typical case is an audio and a video stream as part of a
  videoconference.


v=0
o=MxSIP 0 1849763221 IN IP4 192.168.1.100
s=SIP Call
c=IN IP4 192.168.1.100
t=0 0
m=audio 29100 RTP/AVP 8 0 18 4 98 99
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 red/8000
a=silenceSupp:off - - - -
a=fmtp:4 annexa=no
a=fmtp:98 0-15
a=fmtp:99 98
a=sendrecv
m=audio 0 RTP/SAVP 8 0 18 4 98 99
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723/8000
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 red/8000
a=silenceSupp:off - - - -
a=fmtp:4 annexa=no
a=fmtp:98 0-15
a=fmtp:99 98
a=sendrecv

The offered SDP suggests 2 audio streams, the second M-line has a port ZERO set and therefore MUST NOT be used.

The response also MUST contain both M-lines.
The second M-line can be rejected in the response by setting the port ZERO.
Therefore the Server: Asterisk PBX 1.8.2.4 MUST respond to the SDP with an answer if one of the 2 m-lines is supported by the Server: Asterisk PBX 1.8.2.4.
If none of the m-lines is supported. The 488 answer is correct.

By: Stefan Schmidt (schmidts) 2011-05-13 03:59:29

i uploaded a not malformed patch which helps but only in this special case.

the reporter told me he has found the rfc where this behavior is described in rfc3264. In part 5.1 the definition tells:

In all cases, the formats in the "m=" line MUST be listed in order of
  preference, with the first format listed being preferred.  In this
  case, preferred means that the recipient of the offer SHOULD use the
  format with the highest preference that is acceptable to it.

----

A stream that is offered with a port of zero MUST be marked with port
  zero in the answer.  Like the offer, the answer MAY omit all
  attributes present previously, and MAY list just a single media
  format from amongst those in the offer.

By: Jacco van Tuijl (jacco) 2011-05-13 05:06:13

the patch worked for me :)

By: Jacco van Tuijl (jacco) 2011-05-13 06:49:54

I've uploaded a patch (issue19281_2.patch) that will also fix interoperability with a HiPath 3000 V8 M5T SIP Stack/4.0.26.26 and will make asterisk more compliant with RFC3264.

To be more specific:
it makes astrisk complaint with this line from part 5.1 of RFC3264:
A port number of zero in the offer indicates that the stream is offered but MUST NOT be used

This is my first patch (with license) and I realy hope it will make to the official release

By: Jacco van Tuijl (jacco) 2011-05-23 07:16:41

My license has been formally accepted; patch is now available for download

By: Terry Wilson (twilson) 2011-05-27 11:50:35

Offering two media streams, one encrypted and one unencrypted isn't valid. Look at an offer for voice and video. Two m= lines. You accept both of them. This would be saying to do both encrypted and unencrypted media, which is silly.

Of course, since they are setting the port to 0, it should the SRTP offer should be completely ignored--so this isn't really an offer of SRTP at all. It seems completely dumb for them to send it in that case, but oh well.

A cursory examination of the second patch looks good to me. I'll test it out to make sure.

By: Terry Wilson (twilson) 2011-06-20 12:36:33.525-0500

Committed the second patch to 1.8 and trunk, thanks!