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
1. UPDATE Request during the INVITE transaction
RFC:RFC3311/5.1 Sending an UPDATE (AFAIK)
BCP:I think(hope)
o:MAY send UPDATE with new offer
x:MUST NOT send UPDATE with new offer
#:should not send UPDATE with new offer
1.1. initial INVITE with an offer and PRACK without an offer
+---------------------------+---+--------------------------+
| Caller | | Callee |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP| | | |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | |init-INVITE(offer1)|-->| | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|1xx-rel(answer1) | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | |PRACK(noSDP) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | | | | # | o |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|2xx-PRACK | | |
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
1.2. initial INVITE with an offer and PRACK with an offer
+---------------------------+---+--------------------------+
| Caller | | Callee |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP| | | |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | |init-INVITE(offer1)|-->| | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|1xx-rel(answer1) | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | |PRACK(offer2) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|2xx-PRACK(answer2)| | |
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
1.3. initial INVITE without an offer
+---------------------------+---+--------------------------+
| Caller | | Callee |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP| | | |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | |init-INVITE(noSDP) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|1xx-rel(offer1) | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | |PRACK(answer1) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | | | | # | o |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|2xx-PRACK | | |
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
1.4. re-INVITE with an offer and PRACK without an offer
+---------------------------+---+--------------------------+
| Caller | | Callee |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP| | | |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
| | |re-INVITE(offer1) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|1xx-rel(answer1) | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | | | <see example 1> | # | o |
+---+---+-------------------+---+------------------+===+===+
| | |PRACK(noSDP) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | | | | # | o |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|2xx-PRACK | | |
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
1.5. re-INVITE with an offer and PRACK with an offer
+---------------------------+---+--------------------------+
| Caller | | Callee |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP| | | |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
| | |re-INVITE(offer1) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|1xx-rel(answer1) | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | | | <see example 1> | # | o |
+---+---+-------------------+---+------------------+===+===+
| | |PRACK(offer2) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|2xx-PRACK(answer2)| | |
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
1.6. re-INVITE without an offer
+---------------------------+---+--------------------------+
| Caller | | Callee |
+---+---+-------------------+---+------------------+---+---+
|RFC|BCP| | | |BCP|RFC|
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
| | |re-INVITE(noSDP) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | <see example 2> | | <see example 3> | # | o |
+===+===+-------------------+---+------------------+===+===+
| | | |<--|1xx-rel(offer1) | | |
+---+---+-------------------+---+------------------+---+---+
| x | x | | | | x | x |
+---+---+-------------------+---+------------------+---+---+
| | |PRACK(answer1) |-->| | | |
+---+---+-------------------+---+------------------+---+---+
| o | # | | | | # | o |
+---+---+-------------------+---+------------------+---+---+
| | | |<--|2xx-PRACK | | |
+---+---+-------------------+---+------------------+---+---+
| o | o | | | | o | o |
+---+---+-------------------+---+------------------+---+---+
I correct the prior ideas of mine.
I think, ua should not send the UPDATE request with new offer
at the time of x or #, and ua should reply 491(Request Pending)
for the UPDATE. It is the simplest, I think.
Of course, other idea is smarter for several scenario, but
it might be complex.
example 1.
A B
| |
|re-INVITE(offer1) |
|------------------------------>|
| |
| 1xx-rel(answer1)|
|<------------------------------|
| |
| UPDATE(offer2)|
|<==============================| <- should not send
| |
|491-UPDATE |
should reply 491 -> |==============================>|
| |
|PRACK(offer3) |
Wait until 491 -> |------------------------------>|
| |
| 2xx-PRACK(answer3)|
|<------------------------------|
| |
example 2.
A B
| |
|re-INVITE(noSDP) |
|------------------------------>|
| |
|UPDATE(offer1) |
should not send -> |==============================>|
| |
| 491-UPDATE|
|<==============================| <- should reply 491
| |
| 1xx-rel(offer2)|
|<------------------------------| <- Wait until 491
| |
|PRACK(answer2) |
|------------------------------>|
| |
example 3.
A B
| |
|re-INVITE(noSDP) |
|------------------------------>|
| |
| UPDATE(offer1)|
|<==============================| <- should not send
| |
|491-UPDATE |
should reply 491 -> |==============================>|
| |
| 1xx-rel(offer2)| is offer2 equal to offer1 ?
|<------------------------------|(<- Wait until 491)
| |
|PRACK(answer2) |
|------------------------------>|
| |
2. re-INVITE Request during the UPDATE transaction
it seems a similar case but I think it's another issue.
I think 491 for re-INVITE is the simplest, but wait-until-2xx
is not bad.
example 4.
A B
| |
|UPDATE(offer1) |
|==============================>|
| |
should not send -> |re-INVITE(noSDP) |
|------------------------------>| 491 is the simplest ...?
| |
| 2xx-UPDATE(answer1)|
|<==============================|
| |
| 1xx-rel(offer2)| offer2 should include answer1
|<------------------------------| <- Wait until 2xx-UPDATE
| |
|PRACK(answer2) |
|------------------------------>|
| |
example 5.
A B
| |
| UPDATE(offer1)|
|<==============================|
| |
should not send -> |re-INVITE(noSDP) |
|------------------------------>| 491 is the simplest ...?
| |
|2xx-UPDATE(answer1) |
|==============================>| <- should prepare to 491
| |
| 1xx-rel(offer2)|
|<------------------------------| <- Wait until 2xx-UPDATE
| |
|PRACK(answer2) |
|------------------------------>|
| |
example 6. Glare Case for exsample 5
A B
| |
| UPDATE(offer1)|
| /============|
should not send -> |re-INVITE(noSDP) / |
|----------------/------------->|
| / |
|<=============/ |
| |
|491-UPDATE |
|==============================>| <- should prepare to 2xx
| |
| 1xx-rel(offer2)|
|<------------------------------| <- Wait until 491-UPDATE
| |
|PRACK(answer2) |
|------------------------------>|
| |
Regards,
Shinji
Paul Kyzivat <pkyzivat@xxxxxxxxx>
I just submitted a revised version of the offeranswer draft.
This addresses AD review comments from Jon. Most were superficial. But
Jon had a lot of difficulty with section 4.1, and he wasn't the only
one. So I elected to rewrite it completely. Its now so different that it
needs careful scrutiny technically and editorially.
I intended to address comments by OKUMURA Shinji, but I didn't get to it.
I expect there will be yet another update to capture resolution of the
remaining issues that will hopefully be negotiated at the upcoming meeting.
Thanks,
Paul
-------- Original Message --------
Subject: I-D Action:draft-ietf-sipping-sip-offeranswer-09.txt
Date: Mon, 3 Nov 2008 06:15:01 -0800 (PST)
From: Internet-Drafts@xxxxxxxx
To: i-d-announce@xxxxxxxx
CC: sipping@xxxxxxxx
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Session Initiation Proposal
Investigation Working Group of the IETF.
Title : SIP (Session Initiation Protocol) Usage of the Offer/Answer Model
Author(s) : P. Kyzivat
Filename : draft-ietf-sipping-sip-offeranswer-09.txt
Pages : 27
Date : 2008-11-03
The Session Initiation Protocol (SIP) utilizes the offer/answer
model to establish and update multimedia sessions using the Session
Description Protocol (SDP). The description of the offer/answer
model in SIP is dispersed across multiple RFCs. This document
summarizes all the current usages of the offer/answer model in SIP
communication.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sip-offeranswer-09.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
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
