Subject: Re: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT

From: Takuya Sawada <[email-masked]>
Date: Wed, 2 Nov 2005 18:22:43 +0900

Hi,

Thank you for reading and comments.

Comments inline.
> 
> Hi,
> 
> Comments inline, plus some additional comments on the draft ([CHH])
> 
> >>Table 1: row 4 should have an "O" in the Early column, because the 
> >>reliable 1xx response and the PRACK are both sent within an 
> >>early dialog.
> >> 
> >Yes, PRACK is sent within an early dialog. And 1xx response may be sent
> to establish an early dialog or may be sent 
> >within an early dialog. My intension was to highlite the two types of
> ways to 
> >exchange new offer/answer within an early dialog after the first
> offer/answer is completed and to compare them later.
> >I will clarify this or change this part entirely.  
> 
> CHH: Technically, and it has been brought up on the implementor's list
> every now and then, I guess it's possible to send reliable provisional
> responses and PRACKs, containing offer/answers, also for re-INVITE
> requests. 
> 
[TS] Yes, it is possible for re-INVITE without an SDP.
And it is not allowed to send NEW offer in a reliable provisional
response once offer/answer exchange is completed in the dialog.

> >>Section 2.3: another difference between re-INVITE and UPDATE is that 
> >>re-INVITEs allow the UAS to interact with the callee, while UPDATES 
> >>need to be answered automatically by the UAS. Also, I would 
> >>add a note to that section explaining that re-INVITEs should be
> answered 
> >>immediately unless such user interaction is needed. Otherwise, some 
> >>3pcc flows would break.
> >Make sense. We will add it.
> 
> CHH: I guess this depends on whether my previous comment is valid or
> not.
> 
> I also think it would be to put some words on what "automatically"
> really means. Eventhough user interaction may not be allowed,
> "automatically" to me sounds like the SIP stack is able to generate a
> response without even communicating with some kind of internal "call
> controller" Also, a de-coupled gateway may need to communicate with a
> media gateway before being able to answer. 
> 
[TS] At least I think it makes sense to add some 3pcc flow would be
break if UAS respond with 1xx to re-INVITE.
I am not sure how much and in what circumstances it is recommended not 
to respond with 1xx to re-INVITE. Need more thought.

> 
> In table 4, I think it is important to have a note on point 4, saying
> that only one 1xx-rel can contain a valid offer, since the SDPs in all
> 1xx responses must be identical. Yes, it IS later described in the text,
> and shown in one of the examples, but I think also having a note below
> the table would be good.
> 
[TS] OK.

> Also, when it is said that all 1xx must contain the same SDP, I think it
> would be good to indicate that the rule is per early dialogs. 1xx
> responses on early dialog X will naturally contain different SDPs than
> 1xx responses on early dialog Y.
> 
[TS] Yes. I will add some notes.

> In table 2, I don't like the way offers in PRACKs are rejected. It's a
> very "heavy" procedure, and it would require support of UPDATE
> (re-INVITE cannot be used at this point). I would propose that the PRACK
> 200 OK is sent without SDP, and that means that the offer is rejected.
> No, it's not the cleanest solution in the world, but that is the problem
> with PRACK.
> 
[TS] This is the reason to include the following sentense in 2.2;

   "UA can send a PRACK request with a new offer when acknowledging the
    reliable response. Compared to UPDATE method, using PRACK can save
    messages to be exchanged between the UAs. However, as a PRACK request
    should not be rejected, UA is recommended to send a PRACK request only
    when it is sure that the peer accepts a new offer in a PRACK request."

At a first glance, I feel a little bit strange the solution you proposes,
200 OK without SDP to reject an offer and accept an acknowledgement.
But I admit that the solution of accepting an offer in PRACK and then 
sending new offer with UPDATE will cause several problems.
I really want to put stress on "Offer should not be sent with PRACK 
request unless it is sure to be accepted."
I even want to restrict the PRACK offer usage to the case described in
RFC 3312 and recommend to support UPDATE.

Regards,
Takuya

> Regards,
> 
> Christer
> 
> 
> 
> 
> _______________________________________________
> 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: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Wed, 2 Nov 2005 20:43:58 +0100

Hi,

I don't have the text in front of me, but I THINK it's mentioned
somewhere in RFC3262.

However, I still think it would be good to mention in the BCP, because
we can't say that "only offers that will not be rejected are allowed",
because the offerer can't know that...

Regards,

Christer

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 2. marraskuuta 2005 19:18
> To: Christer Holmberg (JO/LMF)
> Cc: Paul Kyzivat; Takuya Sawada; [email-masked]
> Subject: Re: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT
> 
> Hi,
> 
>  > But, if we include words saying that PRACK should
> > only be used for relatively "safe" offers thay may not be a problem.
> 
> I thought we had added a warning along those lines in one of 
> the specs (RFC 3261, RFC 3262, or RFC 3264), but now I cannot 
> find it. Does anybody remember in which spec it is?... or 
> maybe we simply forgot to add it.
> 
> Gonzalo
>