RFC3264 defined many for offerer's and answerer's behavior while during the modifcation of session parameters. The main aim is session continuity, or say that avoiding media clip during modificaion.
But I find that it is not complete, and something is not precision enough.
1. When should offerer using new parameters?
RFC3264 repeated many times of recv in two(the new and old one) parameters(address, port and so on). But when should the offerer using the new media type is beyond definition.
In point of view, it should be until the offerer find the answer using the new type( in signal level by answer or in media level by media content). But it is not complete:
o offer can be rejected. Using new parameters radically can bring about media clip.
o modification can be emergent, such as domain handover. Delay of using new parameters can also bring about media clip.
In fact:
o if the offer can be rejected, using new parameters as late as possible.
o if the offer should not be rejected(such as domain handover), using new parameters as soon as possible.
So, in point of view, as we can distinguish the part of the modification, we'd better extend one guidance in SDP.
2. With precondition, something can not not precision enough.
Without precondition, offerer can conclude that answerer accept the modifition with the answer.(It is not definitive precision, but practical).
But with precondition, some Offer/Answer pairs and the state of precondition satisfied should be before user's confirmation. So, when should the two side using new parameters?
o Just after the state of precondition satisfied. It may be the radical way, because precondition satisfied and user's confirmation are two differnt things. The answerer can discard all the media with new parameters before user's confirmation, and this would bring about media clip.
o Until 200OK of Re-INVITE can be more reasonable here. But without clear definition, it can bring about media clip too.
So, in point of view, this need further definition.
-------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
