9 Feb
2007
9 Feb
'07
2:11 a.m.
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
------------------------------------------------------------------------
[...]