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

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 31 Oct 2005 17:21:46 +0100

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. 

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

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.

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.

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.

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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 Oct 2005 21:04:29 +0200

Hi Christer,

> No, it's not the cleanest solution in the world, but that is the problem

I guess the intention of this draft is to clarify the offer/answer 
model, as opposed to defining new behavior. What you are suggesting here 
would be new behavior, and so, may be out of scope.

In any case, we already had discussions on this issue a long time ago. 
One of the proposals was to reject the PRACK with an error response, but 
that created other problems. That's why that solution was discarded.

Cheers,

Gonzalo

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 31 Oct 2005 21:02:59 +0100

Hi,

>No, it's not the cleanest solution in the world, but that is the
>problem with PRACK.

>would be new behavior, and so, may be out of scope.

I would not call this defining new behviour. Since it's not defined anywhere, I would call it "best current practise due to missing defined behavoiour", or something like that...

Also, remember that the the calling party will assume the SDP in the 200 (PRACK) is a valid answer, so it will accept it. 

Then, when the UPDATE comes from the called party, assume that the calling party will reject it - or that the new answer from the caller party is something the called party doesn't like. There are all kinds of possible "loops" and strange cases that could occor. Also, there would be no way for the called party to indicate "this is the SDP I sent you before the one you just got in 200 (PRACK), becuase the SDP Session Id can't be decreased.

And, if there is forking, and the called party is forces (based on the offer in the UPDATE) to generate an answer which is not "compatible" with the offers other called parties (due to the forking) have received, it may have to send an UPDATE to all of them also. Etc etc etc etc etc :)

>that created other problems. That's why that solution was discarded.

Yes, I remember that. But, I am not proposing to reject the PRACK. A 200 OK would still be sent, but without a 200 OK.

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 31 Oct 2005 21:14:03 +0100

>>One of the proposals was to reject the PRACK with an error response,
>>but that created other problems. That's why that solution was discarded.
>
>Yes, I remember that. But, I am not proposing to reject the PRACK. A 200
>OK would still be sent, but without a 200 OK.

Without an SDP, that is :)

Regards,

Christer

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 31 Oct 2005 22:21:36 +0100

Hi,

Another thing. I think the first page of the draft should only contain one single sentence, with the biggest font size possible, saying:

"There may be at most one single offer/answer exchange per SIP transaction, always most one single offer/answer exchange per SIP transaction, and never more than one single offer/answer exchange per SIP transaction".

After that, the rest are just details...

Regards,

Christer

-----Original Message-----
From: Christer Holmberg (JO/LMF)
To: Christer Holmberg (JO/LMF); [email-masked] '; Gonzalo Camarillo (JO/LMF)
Cc: 'Takuya Sawada '; [email-masked] '; [email-masked] '
Sent: 31.10.2005 21:14
Subject: RE: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT

Regards,

Christer

---

From: Dean Willis <[email-masked]>
Date: Mon, 31 Oct 2005 16:26:40 -0600

On Oct 31, 2005, at 3:21 PM, Christer Holmberg (JO/LMF) wrote:

>
> Hi,
>
> Another thing. I think the first page of the draft should only  
> contain one single sentence, with the biggest font size possible,  
> saying:
>
> "There may be at most one single offer/answer exchange per SIP  
> transaction, always most one single offer/answer exchange per SIP  
> transaction, and never more than one single offer/answer exchange  
> per SIP transaction".
>

Could we add the words "Don't Panic" immediately above the preceding?  
If we did that, I think we'd have a bestseller.

--
dean