Hi, comment inline. "Ian Elz" <ian.elz@xxxxxxxxxxxx> >Shinji, > >The summary that you have given provides a simple view of the issues. > >It does however highlight some other issues which need to be clarified. > >If I assume that your use of met/notmet refers to precondition >negotiation then the sequence you have described highlights some >specific issues. > >Here is a numbered copy of your sequence: > > signaling | O/A state | media in use > ---------------------+--------------------------------+-------------- >1. init-INVITE/200/ACK | audio1(met) | audio1 >2. re-INVITE/183-rel | audio2(notmet) | audio1 >3. (PRACK/200OK) | audio2(met) +video1(notmet) | audio2 >4. UPDATE/200OK | audio2(met) +video1(met) | audio2+video1 >5. UPDATE/200OK | audio2(met) +video2(notmet) | audio2+video1 > 4xx/ACK | | > Gonzalo's proposal | audio2 +video1 | > Gao's proposal | audio1 +video1(?) | > >1. This is OK. The original SDP offer/answer is agreed. > >2. In the re-INVITE the audio stream is being modified in some way. How >this is being modified will result in whether preconditions are >required. > >3. This creates an issue. The PRACK has made a new SDP offer as part of >the precondition notification AND has also added a new media stream. > >I am unsure if this should be allowed during a precondition negotiation. >Technically it is allowed but is does cloud the issue. Gao has stated in >a separate response that the UPDATE (5.) should be rejected 504, and I >agree with this, but as 3. is a PRACK I am unsure how this modified >offer can be rejected. I would think that the receiving UA should reject >the re-INVITE at this point. > >A simpler scenario would be: > >signaling | O/A state | media in use >---------------------+--------------------------------+-------------- >init-INVITE/200/ACK | audio1(met) | audio1 >re-INVITE/183-rel | audio1(met) +video1(notmet) | audio1 >(PRACK/200OK) | [no sdp] | audio1 >UPDATE/200OK | audio1(met) +video1(met) | audio1+video1 >4xx/ACK | | >Gonzalo's proposal(?)| audio1 +video1 | >Gao's proposal(?) | audio1 | > >I think that the end state should be to return the media back to state >in which it was prior to the re-INVITE. that is full-rollback, isn't it? I like it, too. >The question is how. > >The other issue that you have raised concerning new modification of the >SDP during the precondition modification also needs to be addressed. My >belief is that this modification should be rejected. agree > If the UPDATE with >this modification crosses with the 4xx to the re-INVITE then we are back >to the original issue from section 6.2 of the offeranswer draft. How >does the UAS determine that this transaction is associated with the >original re-INVITE or is a separate standalone transaction? it seems to impossible. >Offer/answer 5 in your original sequence is a modification to an agreed >media stream and requires new precondition negotiation. While >technically this is possible using UPDATE transactions I do not believe >that this should be allowed. Any SDP modification using preconditions >should require use of a re-INVITE. I think so too. >Ian Elz > >-----Original Message----- >From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On >Behalf Of OKUMURA Shinji >Sent: 02 March 2009 09:44 >To: sipping >Cc: Gonzalo Camarillo; Christer Holmberg >Subject: Re: Summary of Closing the offer/answer rollback issue? > >Hi, > >The following table describes my understanding. >Is this right? > >signaling | O/A state | media in use >---------------------+--------------------------------+-------------- >init-INVITE/200/ACK | audio1(met) | audio1 >re-INVITE/183-rel | audio2(notmet) | audio1 >(PRACK/200OK) | audio2(met) +video1(notmet) | audio2 >UPDATE/200OK | audio2(met) +video1(met) | audio2+video1 >UPDATE/200OK | audio2(met) +video2(notmet) | audio2+video1 >4xx/ACK | | > Gonzalo's proposal | audio2 +video1 | > Gao's proposal | audio1 +video1(?) | > > >Regards, >Shinji _______________________________________________ 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
