"The UPDATE *must* contain two m-lines, reflecting its understanding of the current state of both."
Yes. But it is syntax restriction.
And I think that only with specific definition, we can say that the later offer's effect is dependent on the earlier one. Such as preconditon(the "Precondition notification's effect is dependent on the earlier one").
In your example, when the other side recv the UPDATE, it has two choice:
1. If the UA can not accept it(including the new modification part and the part triggered in Re-INVITE) at once, rejecting it with 504.
2. If the UA accept it, all the part in SDP committed(It is the newest share view of session).
| Paul Kyzivat <pkyzivat@xxxxxxxxx>
2009-03-03 23:30 |
|
No. I think that makes no sense at all.
Each offer that is sent is dependent on the ones that went before. If
you accept a later one and then fail an earlier one the state is not
well defined.
For instance, suppose a reINVITE proposes addition of a codec to an
existing audio stream and also addition of a second media stream
(video). Then there is a subsequent UPDATE to modify the original audio
stream (e.g. to make it inactive). That UPDATE *must* contain two
m-lines, reflecting its understanding of the current state of both.
Hence it is dependent on the reINVITE. If there is a 200 response to it,
how can that be handled independently of the subsequent success or
failure of the reINVITE? The response to the UPDATE must address what
was in the offer in the UPDATE, about both streams.
Thanks,
Paul
-------------------------------------------------------- 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
