[Users] RTP fixes for mediaproxy

[Stefan Sayer]

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
> 
> 
> ------------------------------------------------------------------------

[...]

-- 
Stefan Sayer
Media Services Development

Fon +49-30-319 80 41-7007
Fax +49-30-722 39 89 87

stefan.sayer at iptego.de
www.iptego.de

iptego GmbH
Am Borsigturm 40
13507 Berlin
Germany

Amtsgericht Charlottenburg, HRB 101010
Geschaeftsfuehrer: Alexander Hoffmann