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.
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. 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?
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.
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
_______________________________________________
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
