chaitali CK wrote:
Hi Paul,
rfc 3264 says " i-th media stream in the previous SDP must match the ith media stream in new offer. "
The actual quote is:
If an SDP is offered, which is different from the previous SDP, the new SDP MUST have a matching media stream for each media stream in the previous SDP. In other words, if the previous SDP had N "m=" lines, the new SDP MUST have at least N "m=" lines. The i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top. This matching is necessary in order for the answerer to determine which stream in the new SDP corresponds to a stream in the previous SDP. Because of these requirements, the number of "m=" lines in a stream never decreases, but either stays the same or increases. Deleted media streams from a previous SDP MUST NOT be removed in a new SDP; however, attributes for these streams need not be present.
In the sentence:
The i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top.
"matches" really means "corresponds".
My doubt is for every media stream in the new offer , what should we compare against in the old offer.
Transport type/MediaType and Media formats can change . So what should we compare against that present in the old offer.
No matching of values in the m-lines is required - just the ordinal positions matter.
Paul
Thanks,
Chaitali
*/Paul Kyzivat <[EMAIL PROTECTED]>/* wrote:
There has been an evolution of thinking on this subject. Originally (2543 I guess) once a media line had been offered, that particular "slot" in the SDP was taken, and could only be used for the same kind of media. If it was once refused (with a port=0) it could never be used again.
Later, it was concluded that once the slot had been rendered inactive with port=0, it could subsequently be reused. And then it was recognized that if that was ok, then it might as well be possible for a new offer to totally change a "slot" in the SDP to an entirely different media type/transport, etc.
It still should be the case that the replacement media stream be somehow logically a replacement for the prior one.
Whay you suggest, switching from RTP/AVP to RTP/SAVP seem entirely reasonable. Of course, if you do this, you must be prepared for it to fail. This could fail in a couple of ways:
- the reinvite itself could fail. If so, the prior media streams must remain in effect
- the reinvite could succeed, but the media stream in the new offer could be rejected (port=0 in the answer). In that case you still have a call, but the old media stream is gone and there is nothing to replace it.
Paul
[EMAIL PROTECTED] wrote: > Chiatali, > My undertsanding of the section in 3264 you are querying is that > if you offered two m= lines in the original request you need to offer at > least that in the new request and that the ordering of them is preserved, > new media offered should be appended to the previous SDP. So if you > offered audio m= and video m= then you these should be in the new request. > So you m line for audio is still there, you might just be adding another > codec to it, or you may be setting one of them inactive. I hope I am right > ! and I hope the above makes sense. > > Regards - Wayne D. > > > Chiatali asked --> > ***************************** > Hi Wayne, > > But what does the below statement from RFC 3264 means > > " If an SDP is offered, which is different from the previous SDP, the > new SDP MUST have a matching media stream for each media stream in > the previous SDP. The i-th media stream in the previous SDP, counting > from the top,matches the i-th media stream in the new SDP, counting from > the top." > > Is it not that if the 1st media stream in previous offer has RTP as the > protocol then in the Subsequent offers sent the 1st stream must also use > RTP as transport. > > what does matching the media stream mean..? > > Thanks, > Chaitali > > > [EMAIL PROTECTED] wrote: > > Chaitali, > If support for it has been indicated in the signalling from the > UAS (UPDATE listed in the Allow header), the UAC can change the SDP by > sending an UPDATE request (RFC3311), in early or comfirmed dialog - as in > your example below. Or complete the initial INVITE request and then > re-INVITE the UAS with the desired SDP. > > Regards - Wayne D. > > > ********************************************************** > Chaitali asked -> > > Hi All, > I need some clarifications regd Offer Answer Model.User A sends Invite to > UserB with RTP as transport and B accepts the call with 200 > User A SDP: > v=0 > o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com > s= > c=IN IP4 host.atlanta.example.com > t=0 0 > m=audio 49170 RTP/AVP 0 8 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > > and B replies with > v=0 > o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com > s= > c=IN IP4 host.biloxi.example.com > t=0 0 > m=audio 49172 RTP/AVP 0 8 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > > > Can B Send an Updated Offer changing the Transport Is this valid ? > v=0 > o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com > s= > c=IN IP4 host.biloxi.example.com > t=0 0 > m=audio 49172 RTP/SAVP 0 8 > a=rtpmap:0 PCMU/8000 > a=rtpmap:8 PCMA/8000 > > Thanks, > Chaitali > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Search presents - Jib Jab's 'Second Term' > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > ****************************************************************************** > - NOTICE FROM DIMENSION DATA AUSTRALIA > This message is confidential, and may contain proprietary or legally > privileged information. If you have received this email in error, please > notify the sender and delete it immediately. > > Internet communications are not secure. You should scan this message and > any attachments for viruses. Under no circumstances do we accept liability > for any loss or damage which may result from your receipt of this message > or any attachments. > ****************************************************************************** > Do you Yahoo!? > Yahoo! Search presents - Jib Jab's 'Second Term' > _______________________________________________ > Sip-implementors mailing list > [email protected] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors >
------------------------------------------------------------------------
Do you Yahoo!?
Yahoo! Search presents - Jib Jab's 'Second Term' <http://us.rd.yahoo.com/evt=30648/*http://movies.yahoo.com/movies/feature/jibjabinaugural.html>
_______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
