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

From: Takuya Sawada <[email-masked]>
Date: Thu, 11 Oct 2007 22:43:45 +0900

Hi,
> 
> Hi, 
> 
> >>==1. Section 2.1.2 (Invite without SDP)
> >> 
> >>Comment : If the Invite was without an offer, UAS sends the 1xx-rel 
> >>with offer1 and UAC respond with PRACK with answer1. Now if the 
> >>UAS sends the same offer (offer1) in the next 1xx-rel [ As it is a "should" 
> >>condition and UAC behavior is recommended "to ignore" on receiving the
> 
> >>SDP ] UAC will ignore it, but it is no clear if the UAC need to repeat
> >>the SDP answer ( answer1) in the PRACK and may be a problem for the 
> >>UAS, which is expecting the answer SDP in the PRACK. Could  some 
> >>recommendations for the UAC be provided? Similarly if the UAS repeats the offer1 is 200 OK, we 
> >>should specify if there is a need for the UAC to repeat the answer1 in ACK.
> >> 
> >First, I would like to put this paragraph to a 'NOTE'.
> >And as you pointed out, make it clear that UAC is recommended 
> >to repeat the same answer. 
> > 
> >How about the following?
> >---
> >NOTE: UAS should not include SDP in the responses F6 and F9. 
> >However, UAC should prepare to receive the same SDP bodies in 
> >F6 and/or F9 for the case that the peer does not conform to 
> >the recommended implementation. 
> >In this case UAC is recommended to repeat the same SDP in 
> >PRACK and/or ACK.
> 
> [Christer] I don't see why one would need to repeat the answer in
> subsequent PRACKs. Instead I think we could say that the receiver should
> be able to receive "repeated" answers in subsequent PRACKs.
> 
[email-masked]>
Date: Thu, 11 Oct 2007 22:46:27 +0900
Cc: [email-masked], [email-masked], [email-masked],
	[email-masked]

Hi,
> 
> Hi, 
> 
> >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"."
> >---
> 
> [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.
> 
You are right that it may choose to include "previews" in the unreliable
response, because it is not forbidden.
At the same time, it seems to be reasonable to recommend the UAS to send
SDP answer reliably.
How the others think?

> >>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.
> 
> >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 tmmended UAS behavior is not to send repeated SDP in the subsequent
reliable responses. This is the question how UAC react to the non-recommended
UAS behavior. We are not sure what the UAS actually expects.
Here, it is pointed that UAS will expect the same SDP is sent from
UAC in PRACKs. And I tend to agree.

Well, this seems to be problematic.

Of course, this may be one of the strong reasons that UAS should not
include SDP in the subsequent responses.

> >>2. Section 1.1 : 
> >> 
> >>Comment :- Should we also incorporate the recommendation for the UAC, 
> >>which sends out an INVITE without SDP and receives the first 
> >>non-failure reliable response without an Offer due to the UAS not 
> >>conforming to the draft. Does the UAC clear the call or send a PRACK 
> >>and wait for the offer in subsequent reliable responses?
> >> 
> >Well, it is the question how much we should care about the 
> >behaviour not conforming to the RFCs. We can add the sentence 
> >below in 2.1.2.
> > 
> > ---
> >NOTE: UAC, which sends out an INVITE without SDP, may receive 
> >the first non-failure reliable response without an offer, due 
> >to the UAS not conforming to the RFCs. In this case, instead 
> >of just giving up the offer/answer, UAC can send a PRACK and 
> >wait for the offer in subsequent reliable responses, if possible.
> > ---
> > 
> >Or we don't need to say here about such a non-comforming UAS?
> 
> [Christer] I don't mind adding the note, but isn't this case already
> mentioned in chapter 5.3?
> 
Yes, you are right, I think. Then, I prefer not adding the note here.

> Regards,
> Christer
Regards,
Takuya
> 
> 
> _______________________________________________
> 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
> 
> 

--------
Takuya Sawada
KDDI Corporation (KDDI)
Garden Air Tower, 3-10-10, Iidabashi, 
Chiyoda-ku, Tokyo 102-8460, Japan
Tel: +81-3-6678-2997
Fax: +81-3-6678-0286
[email-masked]

_______________________________________________
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: Takuya Sawada <[email-masked]>

> >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.
> 
> [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.

Regarding this point, RFC 3261 says;

      o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.

I think that "preview" is explicitly stated here, but "post(?)view"
is not stated. "in subsequent responses" may be controversial but
it can read until the answer in a reliable non-failure response.
So I think it is not recommended to send SDP after sending the answer.
However, as you point out, there are implementations to have SDP
in every response. Then UAC is recommended to prepare to receive them.

I think the current draft addresses this situation.

> 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.
> 
Yes. It is stated clarly, I think.
> 
> >>>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.
> 
> [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?
> 
OK. This may be redundant statement. However, it may be worth emphasizing, though...
> 
> >>>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 [email-masked]>

Hi,

> >and/or F12, and just ignore them for the case that tle and easy.
> 
> [Christer] I don't understand the "preview of an offer" thing either...
> 
Alright. If there is no opposite opinion, I will try to remove "preview of
an offer".
Be sure that there is no SDP in unreliable response to offerless INVITE.
> 
> >>>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.
> >---
> 
> [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.
> 
Well, you are right. No problem just to remove.
> 
> >>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.
> > ---
> 
> [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.
> 
The difference is that regarding PRACK the draft says that "UA is
recommended to send a PRACK request only when it has strong reasons to
assume the receiver will accept it".
And also, as oppose to the case of the reliable response offer, UAC can
not take care when it sends PRACK because UAC normally cannot be sure if
UAS needs not to be prompted.

Of course we can add in 3.2.

---
Note also that in the case that UAS needs to prompt the user to accept
or reject the offer, PRACK request can result in the retransmission.
---
> 
> >>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).
> 
> [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.
> 
How about adding this case as a note right after the sentence above.

---
NOTE: The behavior above is recommended, but 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. Rejecting
the re-INVITE is also one option, in case the receiver is not able to
generate a new offer which contains "everything".
---

> >>Another thing that might be useful to point out in here - it is legal 
> >>to have UPDATE/2xx exchanges without O/A exchanges.
> >> 
> > 
> he 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.
> 
> [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.

Regarding this point, RFC 3261 says;

      o  If the initial offer is in an INVITE, the answer MUST be in a
         reliable non-failure message from UAS back to UAC which is
         correlated to that INVITE.  For this specification, that is
         only the final 2xx response to that INVITE.  That same exact
         answer MAY also be placed in any provisional responses sent
         prior to the answer.  The UAC MUST treat the first session
         description it receives as the answer, and MUST ignore any
         session descriptions in subsequent responses to the initial
         INVITE.

I think that "preview" is explicitly stated here, but "post(?)view"
is not stated. "in subsequent responses" may be controversial but
it can read until the answer in a reliable non-failure response.
So I think it is not recommended to send SDP after sending the answer.
However, as you point out, there are implementations to have SDP
in every response. Then UAC is recommended to prepare to receive them.

I think the current draft addresses this situation.

> 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.
> 
Yes. It is stated clarly, I think.
> 
> >>>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.
> 
> [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?
> 
OK. This may be redundant statement. However, it may be worth emphasizing, though...
> 
> >>>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 simp>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).
> >---
> 
> [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.
> 
How about;

---
NOTE: It is legal to have UPDATE/2xx exchanges without offer/answer
exchanges (pattern 6). As oppose to that, when re-INVITEs are sent for
non-offer/answer purposes, the current SDP must still be included.
---

--------
Takuya Sawada
KDDI Corporation (KDDI)

le and easy.
> 
> [Christer] I don't understand the "preview of an offer" thing either...
> 
Alright. If there is no opposite opinion, I will try to remove "preview of
an offer".
Be sure that there is no SDP in unreliable response to offerless INVITE.
> 
> >>>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.
> >---
> 
> [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.
> 
Well, you are right. No problem just to remove.
> 
> >>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.
> > ---
> 
> [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.
> 
The difference is that regarding PRACK the draft says that "UA is
recommended to send a PRACK request only when it has strong reasons to
assume the receiver will accept it".
And also, as oppose to the case of the reliable response offer, UAC can
not take care when it sends PRACK because UAC normally cannot be sure if
UAS needs not to be prompted.

Of course we can add in 3.2.

---
Note also that in the case that UAS needs to prompt the user to accept
or reject the offer, PRACK request can result in the retransmission.
---
> 
> >>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).
> 
> [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.
> 
How about adding this case as a note right after the sentence above.

---
NOTE: The behavior above is recommended, but 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. Rejecting
the re-INVITE is also one option, in case the receiver is not able to
generate a new offer which contains "everything".
---

> >>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).
> >---
> 
> [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.
> 
How about;

---
NOTE: It is legal to have UPDATE/2xx exchanges without offer/answer
exchanges (pattern 6). As oppose to that, when re-INVITEs are sent for
non-offer/answer purposes, the current SDP must still be included.
---

--------
Takuya Sawada
KDDI Corporation (KDDI)

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 11 Oct 2007 17:16:54 +0200

Hi,
 
>At the same time, it seems to be reasonable to recommend the UAS to send

[Christer] SDP answers can only be sent reliably - if the SDP is sent unreliably it is not an answer.

I think it such recommendation may only confuse people. Because, if PRACK is not supported, they may think that they will have to send a 200 OK as soon as possible - even if the call hasn't been answered.

I think it would be good to strongly recommend that the answer is sent before media is sent, though, since many implementations will not allow media until they have received an answer.

> >and/or F12, and just ignore them for the case that the peer

>is not stated.

[Christer] No, because in RFC 3261 there are no responses sent after 2xx.

And, since the text says that the UAC MUST treat the first reliable SDP as the answer, implementations shouldn't care whether the "post responses" contain SDP or not.

>"in subsequent responses" may be controversial but

[Christer] The UAC MUST be able to receive them, but the UAC can ignore them.

>OK. This may be redundant statement. However, it may be worth emphasizing, though...

[Christer] Personally I think less-text-is-better, but it's up to you to decide :)

>assume the receiver will accept it".

[Christer] Yes, but that doesn't mean the receiver won't be promted anyway. A "promt" could also be a transaction to a MG using H.248, for example.

>or reject the offer, PRACK request can result in the retransmission.

[Christer] It is also true for UPDATE, I believe.

>generate a new offer which contains "everything".

[Christer] Sounds good, but maybe you could extend a little by saying:

NOTE: The behavior above is recommended, but 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. In those cases the offerer may
choose to offer the currently used SDP, or to reject the re-INVITE request. 

>non-offer/answer purposes, the current SDP must still be included.

[Christer] Sounds good.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Oct 2007 16:37:10 -0400

Takuya - inline.

	Thanks,
	Paul

> At the same time, it seems to be reasonable to recommend the UAS to send

In an open environment where the UAC is unaware of the capabilities of 
the UAS, it is risky to *require* 100rel, because it can result in a 
call failing. Trying with and then failing over to trying without 
suffers from HERFP problems, so also isn't desirable. So it can be 
assumed that in general a UAC that would prefer to use 100rel will 
simply announce support for it.

Clearly the UAS has the option to send reliable responses or not in this 
case, based on local preference. If there is no basis for the UAS having 
a preference in this case then it probably should. I don't know if that 
is strong enough to be a SHOULD, or a MAY.

>>> I would like to add the sentences above in the end of 4.2.5 (Subsequent Offers and Answers).

I'm not sure which sentences this refers to. There are the ones about 
hold, but they don't talk about codecs. Perhaps you meant similar words, 
but modified to talk about codecs?

>> at that point. I think those things should also be mentioned.

There is already language in 4.2.1 about this. It doesn't say 
"everything" - it talks about all or a subset determined by design and 
configuration. Reading that as a whole, it amounts to "the ones it would 
like to use at this time". That might be all, or it might be less than 
all if it is not able to support all at once.

> generate a new offer which contains "everything".

Rejecting the reinvite seems like a *really bad* thing to do. An 
offerles reinvite, soliciting whatever the UAS is willing to use at that 
time, is a common step in many 3pcc call flows. If it fails, then the 
call flow will probably fail.

I don't know how to get this across clearer - that the general idea is 
to say what *you* want *now*, rather than attempting to guess what you 
think the other guy wants you to say. The latter leads to trouble in a 
wide variety of cases.

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 15 Oct 2007 09:42:03 +0200

Hi,

Inline. 

>>>>1. Introduction
>>>>SIP utilizes the offer/answer model to establish and update the 
>>>>session.
>>>>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. This is confusing, since later on the text
says that 
>>>>>>this is a preview 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 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.
>>>>Then, UAC should prepare for the case like this and this 
>>>>case should  be written in this document explicitly.
>>>>
>>>>"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"."
>>>>---
>>>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.
>>>
>>You are right that it may choose to include "previews" in the 
>>unreliable response, because it is not forbidden.
>>At the same time, it seems to be reasonable to recommend the UAS to 
>>send SDP answer reliably.
>>How the others think?
> 
>In an open environment where the UAC is unaware of the 
>capabilities of the UAS, it is risky to *require* 100rel, 
>because it can result in a call failing. Trying with and then 
>failing over to trying without suffers from HERFP problems, 
>so also isn't desirable. So it can be assumed that in general 
>a UAC that would prefer to use 100rel will simply announce 
>support for it.
> 
>Clearly the UAS has the option to send reliable responses or 
>not in this case, based on local preference. If there is no 
>basis for the UAS having a preference in this case then it 
>probably should. I don't know if that is strong enough to be 
>a SHOULD, or a MAY.

[Christer] Since, in many cases, an answer (or, at least a preview of
it) is required in order for media to be accepted (yes, I know 3261 says
one should accept media once the INVITE has been sent) I think we could
be more generic, saying that a UAS SHOULD send an SDP answer reliably
(if possible) before it starts sending media. And, if the UAS does not
support 100rel, it SHOULD send a preview of the answer before it starts
sending media.

>>>>>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'm not sure which sentences this refers to. There are the 
>ones about hold, but they don't talk about codecs. Perhaps 
>you meant similar words, but modified to talk about codecs?
> 
>>>[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"
>"everything" - it talks about all or a subset determined by 
>design and configuration. Reading that as a whole, it amounts 
>to "the ones it would like to use at this time". That might 
>be all, or it might be less than all if it is not able to 
>support all at once.

[Christer] Correct.

>>NOTE: The behavior above is recommended, but 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. 
>>Rejecting the re-INVITE is also one option, in case the receiver is 
>>not able to generate a new offer which contains "everything".
>>---
> 
>Rejecting the reinvite seems like a *really bad* thing to do. 
>An offerles reinvite, soliciting whatever the UAS is willing 
>to use at that time, is a common step in many 3pcc call 
>flows. If it fails, then the call flow will probably fail.
> 
>I don't know how to get this across clearer - that the 
>general idea is to say what *you* want *now*, rather than 
>attempting to guess what you think the other guy wants you to 
>say. The latter leads to trouble in a wide variety of cases.

[Christer] Maybe we could add some text saying: "Even if the UAS is not
able to offer any other SDP that the one currently using, it SHOULD NOT
reject the re-INVITE. Instead, it should generate an offer with the
currently used SDP."

I guess we should also say that the SDP o- line SHALL NOT change in this
case.

Regards,

Christer

---

From: Takuya Sawada <[email-masked]>
Date: Mon, 15 Oct 2007 22:46:35 +0900

Hi Christer, Paul,

Response inline by [Takuya].
> support 100rel, it SHOULD send a preview of the answer before it starts
[Takuya]
Through the discussion so far, I feel it could be better to add Christer's
proposal instead of adding my proposed sentence.
I will not use 'should' instead of 'SHOULD' because this draft is not
intended to be normative document.

How about;

---
Although RFC 3261 says a UA should accept media once the INVITE has been sent,
 in many cases, an answer (or, at least a preview of it) is required in order 
for media to be accepted. Therefore, a UAS should send an SDP answer reliably 
(if possible) before it starts sending media. And, if either the UAC or the 
UAS does not support 100rel, it should send a preview of the answer before it 
starts sending media.
---
> >you meant similar words, but modified to talk about codecs?
[Takuya]
What I mean here is like the below

---
When the new offer is sent in response to an offerless (re)INVITE, 
all codecs supported by the UA are to be included, not just the 
ones that were negotiated by previous offer/answer exchanges. 
Same with media types - so if UA A initially offered audio and 
video to UA B, and they end up with only audio, and UA B sends 
an offerless (re)INVITE to UA A, A's resulting offer should 
re-attempt video, by reusing the zeroed m-line used previously.
---

> I guess we should also say that the SDP o- line SHALL NOT change in this
[Takuya]
So, how about adding the note below following the proposed paragraph
above ("When the new offer is sent ...by reusing the zeroed m-line 
used previously.").

---
NOTE: The behavior above is recommended, but 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. Even if the UAS is not able to offer any other SDP 
that the one currently using, it should not reject the re-INVITE. 
Instead, it should generate an offer with the currently used SDP 
with o- line unchanged.
---

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)