Hi, Mr. Kyzivat, I'm sorry to say that it is not scheduled to attend the meeting. >1. UPDATE Request during the INVITE transaction My tables will be a summary of RFC3311/5.1 Sending an UPDATE. The point of my ideas is as follows. 1.An UPDATE request with new offer should not be sent until the PRACK transaction related to the offer-answer is completed. 2.UA should respond 491 when such UPDATE is received. 3.for this respect, there are no basic differences between init-INVITE and re-INVITE. I think, RFC3311 are too generous to re-INVITE. > 2. re-INVITE Request during the UPDATE transaction Obviously such INVITE should not be sent, but glare case can't be avoided. 3. another issue about Modifying an Existing Session Though it is not referred in draft. RFC3261/14.2 UAS Behavior A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) [Snipping] The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. This rule should adjust to not only 200-OK but also 1xx-rel and PRACK. Regards, Shinji Paul Kyzivat <pkyzivat@xxxxxxxxx> > > >OKUMURA Shinji wrote: >> Hi, >> >> I bring together my ideas. > >There is a lot here that I need to study. So I will not comment >immediately. > >Will you be attending the upcoming ietf meeting? > > Thanks, > Paul _______________________________________________ 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
