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

From: Takuya Sawada <[email-masked]>
Date: Tue, 16 Oct 2007 14:35:51 +0900

Hi Christer,

Inline by [Takuya]

I forgot to response to this mail.
Although some of the comments below has already been addressed in
the previous mails, I repeated here.

> 
> 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.
> 
> [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.
[Takuya]
This point will be noted as responded in the previous mails. Thanks.
> 
> > >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.
> >
> >[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.
> 
> [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.
[Takuya]
Yes.

> >"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.
> 
> [Christer] The UAC MUST be able to receive them, but the UAC can ignore them.
> 
[Takuya]
I agree. I wondered what 'ignore' means in the case of PRACK case.
Now I think we can agree to keep the current text.

> > 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.
..
> 
> [Christer] Personally I think less-text-is-better, but it's up to you to decide :)
> 
[Takuya]
Thanks. I will check it again in the final edit.
> 
> > >>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".
> 
> [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.
[Takuya]
I see.

> >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.
> >---
> 
> [Christer] It is also true for UPDATE, I believe.
> 
[Takuya]
OK. I will add the same text for UPDATE.

> >>>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".
> >---
> 
> [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. 
> 
[Takuya]
As disscussed in another mail, how about changing the last sentence to;

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

> 
> > >>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.
> >---
> 
> [Christer] Sounds good.
> 
> Regards,
> 
> Christer

Regards,
Takuya

--------
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: "Christer Holmberg" <[email-masked]>
Date: Tue, 16 Oct 2007 12:29:58 +0200

Hi, 

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

[Christer] Sounds good. 

Regards,

Christer