Subject: Re: [Sipping] Review of draft-ietf-sipping-offeranswer-02

From: Takuya Sawada <[email-masked]>
Date: Tue, 9 Oct 2007 13:30:17 +0900

Hi Jonathan,

Thank you for the review and comments.
Responses inline.
> 
> Draft:  Review of draft-ietf-sipping-offeranswer-02
> Reviewer: Jonathan Rosenberg
> Review Date: 1 Oct 2007
> Status: WGLC
> 
> Summary:
> 
> This draft is basically ready for publication, but has nits that should 
> be fixed before publication.
> 
> Major comments:
> 
> * the document needs an introduction which explains the purpose of the 
> specification. It kind of jumps right in.
> 
I agree.
It is also pointed out by ID-nits tool <http://tools.ietf.org/tools/idnits/>.

Let me try.

---
1. Introduction
SIP utilizes the offer/answer model to establish and update the session.
The rules to govern the offer/answer behaviors in SIP are described in
the several RFCs.
The primary purpose of this document is to describe the whole set of SIP
usage of the offer/answer model in one document to help the readers to
fully understand it. Also, this document tries to incorporate the 
esults of the discussions on the controversial issues to avoid repeating
the same discussions later.
This document is not intended to create any new normative methods.
Rather, it makes the remaining issues clear and leaves them for further
study.
---
> 
> > An unreliable provisional 
> >        response may include a session description in the body if the UAS has 
> >        not sent a reliable response, but its session description is neither 
> >        an offer nor an answer. 
> 
> This is confusing, since later on the text says that this is a preview 
> answer.
> 
Maybe this question is related to the question on the "preview" of an offer.

> The implication of the text here is that it is valid to send previews in 
> unreliable responses and then the answer in a reliable provisional 
> response. That is a different use case from previews in unreliable 
> provisionals and then the answer in the final response. To be frank, 
> this first case was not contemplated when rfc3264 was written, and I'm 
> not sure we want to make it allowed. 

I understand it is not an intended use case.
However, unreliable responses with SDP is allowed.

I am not sure but some implementation may act like the first case.
Then, UAC should prepare for the case like this and this case 
should be written in this document explicitly.

Of course, we can add the sentence below:

---
"When both UAC and UAS support 100rel, UAS is not recommended to send
 SDP unreliably, because it can send SDP reliably in any response and
 has no reason to use a "preview"."
---

> It raises some more questions like, 
> once the reliable provisional is sent with the answer, and a PRACK comes 
> with an offer, can you send more unreliable provisionals with previews 
> of the next answer, and then the answer in the 200 to PRACK (NO!).
> 
Clearly NO.

We put the following sentence in 2.1.1.

---
UAS does not include an SDP in the responses F9 and F12. However, UAC
should prepare to receive SDP bodies in F9 and/or F12, and just ignore
them for the case that the peer does not conform to the recommended
implementation.
---

Also we can find the sentence below in 2.1.

---
All the session descriptions in the unreliable responses to the INVITE 
request must be identical to the answer which is included in the reliable
response.
---

I hope here we can eliminate the possibility to use "preview" for 
the next answer other than INVITE transaction.
Also there is no such an implementation out there, I hope.

> > When a UAC includes an SDP body in the INVITE request as an offer, it 
> >        expects the answer to be received with one of the reliable responses. 
> >        Other than that, no offer/answer exchanges can occur in the INVITE 3-
> >        way handshake process. 
> 
> This text is confusing; since there can be O/A exchanges in PRACK and 
> UPDATE that occur "in" the 3-way handshake, in that these other 
> exchanges are bounded by the 3-way handshake.
> 
I agree. How about the following change (in 2.1.1 and 2.1.2).

in the INIVTE 3-way handshake process.
-> in the messages within the INVITE transaction.

> > For example, in Figure 2, only the SDP in F3 is the offer. The SDP in 
> >        the non-reliable response (F2) is the preview of the offer and must 
> >        be the same as the offer in F3, but is not officially the offer. 
> 
> Offer previews? Again this is not something envisioned in 3264. Where in 
> there is justification for this?
> 
"Preview" of an offer is the analogy from preview of an answer.
I assume that an SDP in an unreliable response to the INVITE without an offer.

There is no justification to use "preview" of an offer in unreliable responses
in RFC 3261 and RFC 3264, and any other RFCs.

The question is whether we should leave it as a non-conforming UAS case or
just remove it.

Is there any implementation which includes SDP in an unreliable response
to try to tell its SDP offer as soon as possible?
If no, no problem to remove the possibility to receive "preview" of an 
offer from the document. It is simple and easy.

> > UA can send an UPDATE request with a new offer if both ends support 
> >        the UPDATE method. Support for the UPDATE method must be declared in 
> >        an Allow header in some prior messages in the dialog. 
> 
> Not any messages (i.e., error responses) but dialog forming requests and 
> responses.
> 
Thanks.
How about;

---
Support for the UPDATE method must be declared in an Allow header in the
dialog forming requests and responses.
---

> 
> Somewhere in here, should probably mention that a big drawback of doing 
> O/A in 1xx-rel/PRACK is that if the UAC needs to prompt the user to 
> accept or reject the offer, this can result in retransmits of the 1xx 
> until the PRACK can be sent, which is bad.
> 
How about adding the sentence below ieliable responses and then the answer in a reliable provisional 
> response. That is a different use case from previews in unreliable 
> provisionals and then the answer in the final response. To be frank, 
> this first case was not contemplated when rfc3264 was written, and I'm 
> not sure we want to make it allowed. 

I understand it is not an intended use case.
However, unreliable responses with SDP is allowed.

I am not sure but some implementation may act like the first case.
Then, UAC should prepare for the case like this and this case 
should be written in this document explicitly.

Of course, we can add the sentence below:

---
"When both UAC and UAS support 100rel, UAS is not recommended to send
 SDP unreliably, because it can send SDP reliably in any response and
 has no reason to use a "preview"."
---

> It raises some more questions like, 
> once the reliable provisional is sent with the answer, and a PRACK comes 
> with an offer, can you send more unreliable provisionals with previews 
> of the next answer, and then the answer in the 200 to PRACK (NO!).
> 
Clearly NO.

We put the following sentence in 2.1.1.

---
UAS does not include an SDP in the responses F9 and F12. However, UAC
should prepare to receive SDP bodies in F9 and/or F12, and just ignore
them for the case that the peer does not conform to the recommended
implementation.
---

Also we can find the sentence below in 2.1.

---
All the session descriptions in the unreliable responses to the INVITE 
request must be identical to the answer which is included in the reliable
response.
---

I hope here we can eliminate the possibility to use "preview" for 
the next answer other than INVITE transaction.
Also there is no such an implementation out there, I hope.

> > When a UAC includes an SDP body in the INVITE request as an offer, it 
> >        expects the answer to be received with one of the reliable responses. 
> >        Other than that, no offer/answer exchanges can occur in the INVITE 3-
> >        way handshake process. 
> 
> This text is confusing; since there can be O/A exchanges in PRACK and 
> UPDATE that occur "in" the 3-way handshake, in that these other 
> exchanges are bounded by the 3-way handshake.
> 
I agree. How about the following change (in 2.1.1 and 2.1.2).

in the INIVTE 3-way handshake process.
-> in the messages within the INVITE transaction.

> > For example, in Figure 2, only the SDP in F3 is the offer. The SDP in 
> >        the non-reliable response (F2) is the preview of the offer and must 
> >        be the same as the offer in F3, but is not officially the offer. 
> 
> Offer previews? Again this is not something envisioned in 3264. Where in 
> there is justification for this?
> 
"Preview" of an offer is the analogy from preview of an answer.
I assume that an SDP in an unreliable response to the INVITE without an offer.

There is no justification to use "preview" of an offer in unreliable responses
in RFC 3261 and RFC 3264, and any other RFCs.

The question is whether we should leave it as a non-conforming UAS case or
just remove it.

Is there any implementation which includes SDP in an unreliable response
to try to tell its SDP offer as soon as possible?
If no, no problem to remove the possibility to receive "preview" of an 
offer from the document. It is simple and easy.

> > UA can send an UPDATE request with a new offer if both ends support 
> >        the UPDATE method. Support for the UPDATE method must be declared in 
> >        an Allow header in some prior messages in the dialog. 
> 
> Not any messages (i.e., error responses) but dialog forming requests and 
> responses.
> 
Thanks.
How about;

---
Support for the UPDATE method must be declared in an Allow header in the
dialog forming requests and responses.
---

> 
> Somewhere in here, should probably mention that a big drawback of doing 
> O/A in 1xx-rel/PRACK is that if the UAC needs to prompt the user to 
> accept or reject the offer, this can result in retransmits of the 1xx 
> until the PRACK can be sent, which is bad.
> 
How about adding the sentence below in 2.1.2. (INVITE request without SDP)

---
Note that in the case that UAC needs to prompt the user to accept or reject
the offer, the reliable provisional response with an SDP as an offer
(pattern 4) can result in the retransmission until the PRACK request can be
sent. UAC should take care to avoid this situation when it sends the INVITE
request without an SDP.
---

> > When offer2 is in a PRACK request, that is, when a PRACK request to 
> >        acknowledge the reliable provisional response with an answer to the 
> >        offer in the INVITE request contains a session description, UA A 
> >        knows it is an offer.
> 
> This sentence is very hard to follow. It might help if you use offer1 
> and answer1 specifically. Indeed, when you do that, this doesn't seem to 
> make sense. I think its saying that offer2=PRACK, and that there was a 
> reliable provisonal response with an answer, but the figure shows no 
> answers from A to B.... I think you need to show a message sequence 
> diagram for the specific case you are trying to explain.
> 
> > When offer2 is in a reliable provisional response or a successful 
> >        final response, UA A knows it is not the answer to the offer1. 
> 
> It seems the opposite is true. If offer1=INVITE, and then UA A gets a 
> provisional response with an SDP (or a final response), the ONLy thing 
> this can be is the answer to offer1.
> 
> > For a reliable response to a re-INVITE request, UA A can 
> >        detect the offer2 is not the answer1. In this case, UA A can not 
> >        reject offer2 in a reliable response, it is recommended to wait for 
> >        answer1 before sending a PRACK request with the answer to offer2. 
> >        Note that this case only occurs when UA A, while waiting for an 
> >        answer, sends an INVITE request without session description.  
> 
> As above, this is really hard to follow. You need a sequence diagram for 
> this case, and more explanation. It is also unclear why there is a 
> difference here in the invite and re-invite cases.
> 
I totally agree that this section is hard to follow.
It was also pointed out by Nataraju and I tried to improve it. 
The table and diagrams below were suggested before to address his comment.

---
Table 3 summarizes the discussions above. 

offer2 | How to know it's not answer1 | Actions to take
-------+------------------------------+--------------------------
INVITE | Never be an answer           | 491 response 
UPDATE | Glare case for UA A          | with Retry-After
-------+------------------------------+--------------------------
PRACK  | Not a pattern 4. in Table 1. | Wait sending response
       | 1xx-rel must have an answer, | until answer1 is received
       | not an offer.                | 
-------+------------------------------+--------------------------
1xx-rel| Only one INVITE transaction  | Wait sending acknowledge
2xx    | at a time. Then UA can know  | until answer1 is received
-------+------------------------------+--------------------------

NOTE: PRACK and 1xx-rel/2xx case is extremely rare case and easily
avoidable. See Figure 4 and Figure 5.

Table 3. UA's action to the offer (offer2) overtaken the previous
answer (answer1)

 A                               B 
 |                               |
 |                   INV (offer0)| 
 |<------------------------------| 
 | 1xx-rel (answer0)             |
 |------------------------------>| --+
 |offer1(e.g. UPD)               |   |
 |==============================>|   |
 |              answer1 (2xx-UPD)|   | Acknowledge
 |<===========\  /===============|   |
 |             \/                |   |
 |             /\     offer2(PRA)|   |
 |<===========/  \===============| <-+
 | answer2 (2xx-PRA)             |
 |------------------------------>| Wait until answer1
 |                               |

Figure 4	PRACK as a message with offer2 in message cross case

 A                               B 
 |                               |
 |offer1(e.g. UPD)               | 
 |==============================>| 
 |re-INV (no offer)              |
 |----------n 2.1.2. (INVITE request without SDP)

---
Note that in the case that UAC needs to prompt the user to accept or reject
the offer, the reliable provisional response with an SDP as an offer
(pattern 4) can result in the retransmission until the PRACK request can be
sent. UAC should take care to avoid this situation when it sends the INVITE
request without an SDP.
---

> > When offer2 is in a PRACK request, that is, when a PRACK request to 
> >        acknowledge the reliable provisional response with an answer to the 
> >        offer in the INVITE request contains a session description, UA A 
> >        knows it is an offer.
> 
> This sentence is very hard to follow. It might help if you use offer1 
> and answer1 specifically. Indeed, when you do that, this doesn't seem to 
> make sense. I think its saying that offer2=PRACK, and that there was a 
> reliable provisonal response with an answer, but the figure shows no 
> answers from A to B.... I think you need to show a message sequence 
> diagram for the specific case you are trying to explain.
> 
> > When offer2 is in a reliable provisional response or a successful 
> >        final response, UA A knows it is not the answer to the offer1. 
> 
> It seems the opposite is true. If offer1=INVITE, and then UA A gets a 
> provisional response with an SDP (or a final response), the ONLy thing 
> this can be is the answer to offer1.
> 
> > For a reliable response to a re-INVITE request, UA A can 
> >        detect the offer2 is not the answer1. In this case, UA A can not 
> >        reject offer2 in a reliable response, it is recommended to wait for 
> >        answer1 before sending a PRACK request with the answer to offer2. 
> >        Note that this case only occurs when UA A, while waiting for an 
> >        answer, sends an INVITE request without session description.  
> 
> As above, this is really hard to follow. You need a sequence diagram for 
> this case, and more explanation. It is also unclear why there is a 
> difference here in the invite and re-invite cases.
> 
I totally agree that this section is hard to follow.
It was also pointed out by Nataraju and I tried to improve it. 
The table and diagrams below were suggested before to address his comment.

---
Table 3 summarizes the discussions above. 

offer2 | How to know it's not answer1 | Actions to take
-------+------------------------------+--------------------------
INVITE | Never be an answer           | 491 response 
UPDATE | Glare case for UA A          | with Retry-After
-------+------------------------------+--------------------------
PRACK  | Not a pattern 4. in Table 1. | Wait sending response
       | 1xx-rel must have an answer, | until answer1 is received
       | not an offer.                | 
-------+------------------------------+--------------------------
1xx-rel| Only one INVITE transaction  | Wait sending acknowledge
2xx    | at a time. Then UA can know  | until answer1 is received
-------+------------------------------+--------------------------

NOTE: PRACK and 1xx-rel/2xx case is extremely rare case and easily
avoidable. See Figure 4 and Figure 5.

Table 3. UA's action to the offer (offer2) overtaken the previous
answer (answer1)

 A                               B 
 |                               |
 |                   INV (offer0)| 
 |<------------------------------| 
 | 1xx-rel (answer0)             |
 |------------------------------>| --+
 |offer1(e.g. UPD)               |   |
 |==============================>|   |
 |              answer1 (2xx-UPD)|   | Acknowledge
 |<===========\  /===============|   |
 |             \/                |   |
 |             /\     offer2(PRA)|   |
 |<===========/  \===============| <-+
 | answer2 (2xx-PRA)             |
 |------------------------------>| Wait until answer1
 |                               |

Figure 4	PRACK as a message with offer2 in message cross case

 A                               B 
 |                               |
 |offer1(e.g. UPD)               | 
 |==============================>| 
 |re-INV (no offer)              |
 |------------------------------>| --+
 |              answer1 (2xx-UPD)|   |
 |<===========\  /===============|   | The first reliable response
 |             \/          offer2|   |
 |             /\   (1xx-rel/2xx)|   |
 |<===========/  \===============| <-+
 | answer2 (PRACK/ACK)           |
 |------------------------------>| Wait until answer1
 |                               |

Figure 5 Reliable response as a message with offer2 in message cross case
---

I hope the proposed changes address your concern.
Maybe not enough, though.

> > The receipt of an offer containing "a=sendonly" or "a=inactive" and 
> >        the sending of a compatible answer should not change the desired 
> >        state of the recipient. 
> 
> Right - but I still think this is not being clear enough here. I think 
> the text needs to be realy clear in saying, "if UA A has placed UA B on 
> hold by means of an a=sendonly or a=inactive, but UA B themselves had 
> not placed the call on hold, when UA B sends an offer (perhaps in 
> response to an offerless INVITE to A), UA B does NOT indicate a=inactive 
> or a=recvonly, but rather, whatever it would normally send had UA A not 
> placed the call on hold". It should also be stated somewhere that not 
> following this guidance can cause calls to be permanently on hold.
> 
We added the following paragraph in this section in -03.
I think it can address your concern here.
(As I can guess it from your mail title, maybe you see -02 version,
 which is older version)

---
If a UA has occasion to send another offer in the session, without any
desire to change the hold status (e.g. in response to a re-INVITE without
an offer, or when sending a re-INVITE to refresh the session timer) it
should follow the General Principle for Constructing Offers and Answers
(section 4.1. ). If it previously initiated a "hold" by sending
"a=sendonly" or "a=inactive" then it should offer that again. If it had
not previously initiated "hold" then it should offer "a=sendrecv", even
if it had previously been forced to answer something else. Without this
behavior it is possible to get "stuck on hold" in some cases, especially
when a third-party call controller is involved. 
---

> Also the text should talk about codecs to send in a new offer. This is 
> particularly troubling when the new offer is sent in response to an 
> offerless INVITE. I think the text should explicitly state that all 
> codecs supported by the UA are to be included, not just the ones that 
> were negotiated by previous O/A exchanges. Same with media types - so if 
> A initially offered audio and video to B, and they end up with only 
> video, and B sends an offerless INVITE to A, A's resulting offer should 
> re-attempt video, by reusing the zeroed m-line used previously.
> 
I would like to add the sentences above in the end of 4.2.5 (Subsequent
Offers and Answers).
> 
> > To resolve this issue may be beyond the scope of this document and 
> >        require another normative document which is for further study. 
> 
> Not just may, "is beyond" the scope.
> 
I agree. And We have already updated in -03 as below.

---
Resolution is beyond the scope of this document, and will require a new
normative document. Such a document is the responsibility of the SIP
working group, and is for further study.
---

> > For example, in Figure 1, only the SDP in F6 is the answer. The SDP 
> >        in the non-reliable response (F2) is the preview of the answer and 
> >        must be the same as the answer in F6, but is not officially the 
> >        answer.
> 
> I think the text needs to be much more clear on what it means to be 
> 'official' and not official. Really, the ONLY thing is that the O/A 
> transaction is not closed by the preview, thus making further exchanges 
> in either direction illegal until the proper answer. Thats it.
>
I agree. I think it is better to remove the phrase ", but is not officially the
answer" and not to use 'official answer' in the document. I will change
the expression in Figure 1 to remove the word.
> 
> Another thing that might be useful to point o-------------------->| --+
 |              answer1 (2xx-UPD)|   |
 |<===========\  /===============|   | The first reliable response
 |             \/          offer2|   |
 |             /\   (1xx-rel/2xx)|   |
 |<===========/  \===============| <-+
 | answer2 (PRACK/ACK)           |
 |------------------------------>| Wait until answer1
 |                               |

Figure 5 Reliable response as a message with offer2 in message cross case
---

I hope the proposed changes address your concern.
Maybe not enough, though.

> > The receipt of an offer containing "a=sendonly" or "a=inactive" and 
> >        the sending of a compatible answer should not change the desired 
> >        state of the recipient. 
> 
> Right - but I still think this is not being clear enough here. I think 
> the text needs to be realy clear in saying, "if UA A has placed UA B on 
> hold by means of an a=sendonly or a=inactive, but UA B themselves had 
> not placed the call on hold, when UA B sends an offer (perhaps in 
> response to an offerless INVITE to A), UA B does NOT indicate a=inactive 
> or a=recvonly, but rather, whatever it would normally send had UA A not 
> placed the call on hold". It should also be stated somewhere that not 
> following this guidance can cause calls to be permanently on hold.
> 
We added the following paragraph in this section in -03.
I think it can address your concern here.
(As I can guess it from your mail title, maybe you see -02 version,
 which is older version)

---
If a UA has occasion to send another offer in the session, without any
desire to change the hold status (e.g. in response to a re-INVITE without
an offer, or when sending a re-INVITE to refresh the session timer) it
should follow the General Principle for Constructing Offers and Answers
(section 4.1. ). If it previously initiated a "hold" by sending
"a=sendonly" or "a=inactive" then it should offer that again. If it had
not previously initiated "hold" then it should offer "a=sendrecv", even
if it had previously been forced to answer something else. Without this
behavior it is possible to get "stuck on hold" in some cases, especially
when a third-party call controller is involved. 
---

> Also the text should talk about codecs to send in a new offer. This is 
> particularly troubling when the new offer is sent in response to an 
> offerless INVITE. I think the text should explicitly state that all 
> codecs supported by the UA are to be included, not just the ones that 
> were negotiated by previous O/A exchanges. Same with media types - so if 
> A initially offered audio and video to B, and they end up with only 
> video, and B sends an offerless INVITE to A, A's resulting offer should 
> re-attempt video, by reusing the zeroed m-line used previously.
> 
I would like to add the sentences above in the end of 4.2.5 (Subsequent
Offers and Answers).
> 
> > To resolve this issue may be beyond the scope of this document and 
> >        require another normative document which is for further study. 
> 
> Not just may, "is beyond" the scope.
> 
I agree. And We have already updated in -03 as below.

---
Resolution is beyond the scope of this document, and will require a new
normative document. Such a document is the responsibility of the SIP
working group, and is for further study.
---

> > For example, in Figure 1, only the SDP in F6 is the answer. The SDP 
> >        in the non-reliable response (F2) is the preview of the answer and 
> >        must be the same as the answer in F6, but is not officially the 
> >        answer.
> 
> I think the text needs to be much more clear on what it means to be 
> 'official' and not official. Really, the ONLY thing is that the O/A 
> transaction is not closed by the preview, thus making further exchanges 
> in either direction illegal until the proper answer. Thats it.
>
I agree. I think it is better to remove the phrase ", but is not officially the
answer" and not to use 'official answer' in the document. I will change
the expression in Figure 1 to remove the word.
> 
> Another thing that might be useful to point out in here - it is legal to 
> have UPDATE/2xx exchanges without O/A exchanges.
> 

Yes. I will add the sentence below in 1.1.

---
NOTE: It is legal to have UPDATE/2xx exchanges without offer/answer
exchanges (pattern 6).
---
> 
> Nits:
> 
> > SIP (Session Initiation Protocol) Usage of Offer/Answer Model 
> >                      draft-ietf-sipping-sip-offeranswer-02.txt 
> 
> Title should include a "the" between "of" and "Offer/Answer". This error 
> occurs throughout the document, in fact.
> 
All right. I will fix them. Thanks.

> Table 1: suggest that, instead of "X" and "O", use "Y" and "N" which are 
> less ambiguous. In particular, "Y" means that the model can be used in 
> the given situation, "N" means it cannot.
> 
Yes, I agree.

> > Note that an offer/answer exchange initiated by an INVITE request 
> >        must follow exactly one of the patterns 1, 2, 3, 4. 
> 
> I think this is meaning to say, "All INVITE transactions result in an 
> offer/answer exchange, and that exchange will be patterns 1,2,3 or 4.". 
> I think its also worth noting here that there can be additional O/A 
> exchanges in the provisional responses, which are very much part of the 
> INVITE transaction, and so this can be confusing.
>
Well, I think that there are NO additional O/A echanges in the INVITE
transaction. Do I miss something?
 
> Thanks,
> Jonathan R.
Regards,
Takuya
 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 10 Oct 2007 03:23:51 +0200

Hi, 

>The rules to govern the offer/answer behaviors in SIP are 
>described in the several RFCs.
>The primary purpose of this document is to describe the whole 
>set of SIP usage of the offer/answer model in one document to 
>help the readers to fully understand it. Also, this document 
>tries to incorporate the esults of the discussions on the 
>controversial issues to avoid repeating the same discussions later.
>Rather, it makes the remaining issues clear and leaves them 
>for further study.
>---
>> 
>>>An unreliable provisional response may include a session description
in the 
>>>body if the UAS has not sent a reliable response, but its session 
>>>description is neither an offer nor an answer. 
>> 
answer.
>>The implication of the text here is that it is valid to send previews 
>>in unreliable responses and then the answer in a reliable provisional 

>"When both UAC and UAS support 100rel, UAS is not recommended 
>to send  SDP unreliably, because it can send SDP reliably in 
>any response and  has no reason to use a "preview"."
>---

[Christer] I don't think we shall speclate whether there is a "reason"
or not. If PRACK is supported (but not required), the UAS can choose to
send provisional response reliably or un-reliable, and it may choose to
include "previews" in the un-reliable ones.

>>It raises some more questions like, once the reliable provisional is
sent with the answer, and a PRACK 
>>comes with an offer, can you send more unreliable provisionals with
previews of the next answer, and then the answer in >>the 200 to PRACK
(NO!).
>Clearly NO.

[Christer] I agree. There is no such thing as a "next answer" within a
single transaction.

>UAS does not include an SDP in the responses F9 and F12. 
>However, UAC should prepare to receive SDP bodies in F9 
>and/or F12, and just ignore them for the case that the peer 
>does not conform to the recommended implementation.
>---
> 
>All the session descriptions in the unreliable responses to 
>the INVITE request must be identical to the answer which is 
>included in the reliable response.
>---
> 
>I hope here we can eliminate the possibility to use "preview" 
>for the next answer other than INVITE transaction.

[Christer] I think the UAS should be allowed to include SDP in F9 and
F12 (there are implementations that always include the answer in 200 OK,
even if it has been sent reliably earlier). If we start making too many
restrictions, without any technical reason, this document will end up
being useless, because lots of implementations will not be conformant to
it.

I think the important thing is to make it clear that, within a single
INVITE transaction, all non-error responses that carry SDP must carry
the SAME SDP.

>in the INIVTE 3-way handshake process. -> in the messages within the
INVITE transaction.

[Christer] I think it's enough to say "as part of (or within) the INVITE
transaction". Because, don't we have a generic statement somewhere
saying that one single SIP transaction can be used for at most one
single offer/answer transaction?

>>Offer previews? Again this is not something envisioned in 3264. Where 
>>in there is justification for this?
>> 
>There is no justification to use "preview" of an offer in 
>unreliable responses in RFC 3261 and RFC 3264, and any other RFCs.
> 
>The question is whether we should leave it as a 
>non-conforming UAS case or just remove it.
> 
>Is there any implementation which includes SDP in an 
>unreliable response to try to tell its SDP offer as soon as possible?
>If no, no problem to remove the possibility to receive 
>"preview" of an offer from the document. It is simple and easy.

[Christer] I don't understand the "preview of an offer" thing either...

>>Not any messages (i.e., error responses) but dialog forming requests 
>>and responses.
>> 
>Thanks.
>How about;
> 
>---
>Support for the UPDATE method must be declared in an Allow 
>header in the dialog forming requests and responses.
>---

[Christer] I am not sure whether this spec needs to say anything about
how clients know that UPDATE can be used, how client know that PRACK can
be used, etc etc etc. That has nothing to do with offer/answer as such.

But, if we want to say something I think it should be more generic -
just a reference to the parts of 3261.

>>Somewhere in here, should probably mention that a big drawback of
doing O/A in 1xx-rel/PRACK is that if the UAC needs to 
>>prompt the user to accept or reject the offer, this can result in 
>>retransmits of the 1xx until the PRACK can be sent, which is bad.
>> 
>Note that in the case that UAC needs to prompt the user to 
>accept or reject the offer, the reliable provisional response 
>with an SDP as an offer (pattern 4) can result in the 
>retransmission until the PRACK request can be sent. UAC 
>should take care to avoid this situation when it sends the 
>INVITE request without an SDP.
> ---

[Christer] Don't we have a similar case when the PRACK carries an offer?
If the receiver needs to be promted, it will cause re-transmissions of
the PRACK.

>>offerless INVITE.
>>I think the text should explicitly state that all codecs supported by
the UA are to be included, not just the 
>>ones that were negotiated by previous O/A exchanges. Same with media
types - so if A initially offered audio and video >>to B, and they end
up with only video, and B sends an offerless INVITE to A, A's resulting
offer 
>>should re-attempt video, by reusing the zeroed m-line used previously.
>> 
Offers and Answers).

[Christer] This can be recommended behaviour, but at the same time it is
not always to achieve - for example in some interworking scenarios. Or,
the offerer may simply not have enough resources to offer "everything"
at that point. I think those things should also be mentioned.

>>Another thing that might be useful to point out in here - it is legal 
>>to have UPDATE/2xx exchanges without O/A exchanges.
>> 
> 
>NOTE: It is legal to have UPDATE/2xx exchanges without 
>offer/answer exchanges (pattern 6).
>---

[Christer] In that case I guess we could also say that there are cases
when re-INVITEs are sent for non-offer/answer purposes, but that the
current SDP must still be included.

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 10 Oct 2007 03:28:34 +0200

Addition to previous comment...
  
>>>offerless INVITE. I think the text should explicitly state that all
codecs 
>>>supported by the UA are to be included, not just the ones that were 
>>>negotiated by previous O/A exchanges. Same with media types - so if A

>>>initially offered audio and video >>to B, and they end up with only
video, and B sends an offerless INVITE to A, A's 
>>>resulting offer should re-attempt video, by reusing the zeroed m-line
used previously.
>>> 
>>I would like to add the sentences above in the end of 4.2.5 
>(Subsequent Offers and Answers).
> 
>[Christer] This can be recommended behaviour, but at the same 
>time it is not always to achieve - for example in some 
>interworking scenarios. Or, the offerer may simply not have 
>enough resources to offer "everything" at that point. I think 
>those things should also be mentioned.

[Christer] I guess rejecting the re-INVITE is also one option, in case
the receiver is not able to generate a new offer which contains
"everything".

Regards,

Christer