[asterisk-dev] Asterisk Media Architecture project

[Kevin P. Fleming]

On 05/12/2011 06:00 AM, Stefan Schmidt wrote:
> Hello david,
>
> i have found an interesting problem with the media archeticture in asterisk.
>
> if possible take a short look at issue 19281. in there is a sip invite
> message from a siemens hipath system which has two media descprition parts.
>
> one with normal RTP and another with SRTP. the second with srtp is wrong
> cause there is no port number and a=sendrecv but by looking at this i
> found another problem.
>
> i have talked with Oej about this and he also thinks that these two
> stream offers are simultanious, but valid in this way. But asterisk will
> overwrite the data from the first stream cause its the same type.
>
> so in this case the siemens offers srtp and rtp as a fallback and cause
> this is rfc valid we should also honor this in asterisk. But this will
> not work.

It is compliant with the RFCs, but it is an offer for *two* media 
streams, not alternate offers for the same media stream. The existing 
RFCs do not have any mechanism defined for offering alternates for the 
same media stream (beyond media formats), and so UAs that want to offer 
both RTP/AVP and RTP/SAVP have had to come up with some method of doing 
so. The more common method seems to be offering RTP/SAVP with 
'crypto=optional', which indicates the offeror is willing to fall back 
to RTP/AVP for that media stream.

There are new RFCs on the way that offer the ability to do what is 
needed here (capability negotiation), but for now any attempt to offer 
'optional' SRTP is a hack and all UAs that want to support it have to 
support the same 'hack' methods of doing so. In order to support this 
particular method, Asterisk would need to be taught to recognize this 
pattern and deal with it... which is entirely separate from supporting 
multiple media streams of the same type.

It does appear that there is a bug though; once Asterisk has parsed an 
offer for a media stream of a particular type, it should completely 
ignore (and generate warnings for) additional stream offers of the same 
type, not overwrite the one it already parsed.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org