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:
- 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:
- 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.
- 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
[...]