Hi,
I bring together my ideas.
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
