[Users] RTP fixes for mediaproxy

[Jeff Williams]

This is from rfc3264. From my reading that says that the "o=" line can
either be identical (streams have not changed) or have the version
incremented by one (streams have changed). Any other changes to the "o="
line for the same session are not valid, i.e. a malformed SDP. Read
section 8.1, to add a new stream you should increment the "o=" line
version by one and either add a new "m=" line or replace a disabled "m="
line.

Either way, the openser module part of mediaproxy ignores the "o=" line
and only looks at the "m=" lines. I can't see where this would be a
problem since UA's should not be changing the "o=" line mid call.

Jeff

Stefan Sayer wrote:
> Hello,
>
> I came across re-Invites modifying a session in another context, and
> noticed the following:
> if you go after 3264 you need to check in o= line in the SDP of the
> re-Invite whether one stream of the re-Invite matches a stream of the
> original Invite. You could be dropping the original stream by assuming
> that the stream from the re-Invite replaces a stream from the previous
> SDP without looking at the owner. - See 8 Modifying the Session:
> "... When issuing an offer that modifies the session,
>    the "o=" line of the new SDP MUST be identical to that in the
>    previous SDP, except that the version in the origin field MUST
>    increment by one from the previous SDP.  If the version in the origin
>    line does not increment, the SDP MUST be identical to the SDP with
>    that version number. ..."
>
> The question is: is a new SDP with different o= line a malformed SDP
> or is it the request to add that stream? I see UAs that interpret it
> as 'leave the current stream and add another stream'.
>
> I have just quickly scanned the mediaproxy module's source, but I
> havent found anything about parsing the o= line.
>
> Stefan
>
> Jeff Williams wrote:
>> Hi,
>>
>> I was having a few issues with mediaproxy when it came to re-invites and
>> call setup where the SDP does not get sent with the first INVITE. I
>> noticed this was due a couple couple of assumptions in mediaproxy which
>> don't always hold:
>>
>> 1) That SDP is always set up first by the caller (i.e. in the INVITE)
>> then updated by the called party (i.e. in the 200). This is not the
>> case. The first SDP can be sent in the 200 response by the called party
>> and the caller send their SDP in the ACK.
>> 2) That RTP streams don't change once set up. This is wrong for
>> reINVITEs.
>>
>> This would cause problems when a user agent sent a reINVITE to redirect
>> RTP to on hold music for example - the RTP change would be ignored. I
>> think this had an impact on some fax setups as well, but I haven't
>> tested it. I found a patch to fix this by storing the streams in a hash
>> by media type, but that is a limiting assumption also (maybe I want 2
>> audi streams?).
>>
>> The attached patch fixes this by changing the following:
>>
>> 1) This pathc allows a mediaproxy RTPSession to be set up by either the
>> caller or called party. A 'caller' argument is passed to the RTPSession
>> functions telling it if the caller or called party is doing the setup or
>> update.
>>
>> 2) The official mediaproxy does not even look at SDP details for streams
>> which are already set up. This patch lets every SDP packet update all of
>> the RTP streams for that party (either caller or called).
>>
>> If you have issues with one-way-audio with media proxy after reINVITEs,
>> have calls the first SDP from the called party or are just plain
>> adventurous, please give it a go. It has been used in a production
>> environment for a bit over a month now. The patch was made against
>> mediaproxy 1.7.2, but will work against 1.8.0 as well since none of the
>> rtphander.py code changed.
>>
>> Regards,
>> Jeff
>>
>>
>> ------------------------------------------------------------------------
>
> [...]
>