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 >> >> >> ------------------------------------------------------------------------ > > [...] > _______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
