Subject: [Sipping] another two questions on draft-ietf-sipping-race-examples-04

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Mon, 10 Sep 2007 15:01:50 +0800

Hi,
 
I've got another two questions on draft-ietf-sipping-race-examples-04
 
A. In Appendix E.  Forking and receiving new To tags, 
        Figure 4. Receiving 1xx responses with different To tags
 
There's a term "mortal early dialog" and an explanation there, 
however, I think the term is rather vague, my gut feeling when first
sight of the "mortal early dialog" 
is any early dialog in mortal state, however, looks like it's not from
the explanation.
 
And from Figure 4, the early dialog is terminated, what does the
"terminated" mean here?
1. BYE sent, 2. CANCEL sent, 3, session terminated locally, 4. dialog
destroyed locally ?
 
B. there's an early dialog construction question in RFC3261 bothers me a
lot, 
does 1xx response to INVITE without contact header, whereas with to tag
create early dialog?

RFC3261
12.1.1 UAS behavior
   When a UAS responds to a request with a response that establishes a
   dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route
   header field values from the request into the response (including the
   URIs, URI parameters, and any Record-Route header field parameters,
   whether they are known or unknown to the UAS) and MUST maintain the
   order of those values.  The UAS MUST add a Contact header field to
   the response. 
 
>From statements above looks like, response MUST have contact header to
create dialog.
However, statements here is rather obscure, 
1. the example is specific to 2xx
2. only say dialog, early dialog not mentioned
 
since this draft's main mission is clarification of RFC32161, 
could the draft add some statements in the dialog state transition
diagram to clarify issue above?
 
Thanks

Regards,
Rockson Li (Zhengyu Li)

Software Engineer
Cisco R&D Center, Shanghai, PRC
Phone(Office) : (8621) 24057003
Email: [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: Miki HASEBE <[email-masked]>
Date: Tue, 11 Sep 2007 10:45:05 +0900

Hi,

The answer is inline.

> is any early dialog in mortal state, however, looks like it's not from

The "mortal early state" is not "early dialog in mortal state".
Here, when two or more early dialog is established by fork,
the early dialog which did not receive 2xx is called "mortal early state".
In other words, although the early dialog remain in existance,
it is destined to terminate after 64*T1.

> 1. BYE sent, 2. CANCEL sent, 3, session terminated locally, 4. dialog

The early dialog is terminated in Figure 4 when the original INVITE
transaction is completed.
If the INVITE transaction is completed in UAC,
all other early dialog which have not received 2xx will be terminated.

The following is the extract of section 13.2.2.4.

   The UAC core considers the INVITE transaction completed 64*T1 seconds
   after the reception of the first 2xx response.  At this point all the
   early dialogs that have not transitioned to established dialogs are
   terminated.

> diagram to clarify issue above?

I think that the term "dialog" here includes the early dialog.
Although not clearly described in section 12.1.1,
I think that 180 and other 1xxs are also included in "such as" which is
described in "such as a 2xx to INVITE".
(Probably, in page 162 of RFC3261, a Contact header of 1xx is "o" which shows
 only that a 100 does not contain it.)
A Contact header is required for the response which constructs a dialog as
described in section 12.1.1.

Thank you,
Miki

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Tue, 11 Sep 2007 09:59:07 +0800

Hi Miki,

Thanks for your reply.

So for question 1 on "mortal early dialog", I think it probably means
the early dialog would be terminated locally, 
without sending of any message explicitly, does it?

For question 2 on 1xx resp establishing early dialog,
Yes, as you said, "in page 162 of RFC3261, a Contact header of 1xx is
"o"", but how does it prove it only applies to 100,
Since from the table, it clearly shows any 1xx resp can take contact
header optionally.

I think there're two categories of 1xx response, which intends to create
early dialog and which not.
For those who intends to create early dialog as said in RFC3261 "12.1.1
UAS behavior", must have Contact header.
Since as you said, it's not clearly described in section 12.1.1, I
wonder if you can make it clearer in this draft?

Thanks

Regards,
-Rockson 

-----Original Message-----
From: Miki HASEBE [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 9:45 AM
To: Rockson Li (zhengyli)
Cc: [email-masked]; Paul Kyzivat (pkyzivat);
[email-masked]; [email-masked];
[email-masked]
Subject: Re: another two questions on
draft-ietf-sipping-race-examples-04

Hi,

The answer is inline.

The "mortal early state" is not "early dialog in mortal state".
Here, when two or more early dialog is established by fork, the early
dialog which did not receive 2xx is called "mortal early state".
In other words, although the early dialog remain in existance, it is
destined to terminate after 64*T1.

The early dialog is terminated in Figure 4 when the original INVITE
transaction is completed.
If the INVITE transaction is completed in UAC, all other early dialog
which have not received 2xx will be terminated.

> B. there's an early dialog construction question in RFC3261 bothers me

> a lot, does 1xx response to INVITE without contact header, whereas 
> with to tag create early dialog?
>     
>  
> RFC3261
> 12.1.1 UAS behavior

> create dialog.
> However, statements here is rather obscure, 1. the example is specific

> to 2xx 2. only say dialog, early dialog not mentioned
>  
> since this draft's main mission is clarification of RFC32161, could 
> the draft add some statements in the dialog state transition diagram 
> to clarify issue above?

I think that the term "dialog" here includes the early dialog.
Although not clearly described in section 12.1.1, I think that 180 and
other 1xxs are also included in "such as" which is described in "such as
a 2xx to INVITE".
(Probably, in page 162 of RFC3261, a Contact header of 1xx is "o" which
shows  only that a 100 does not contain it.) A Contact header is
required for the response which constructs a dialog as described in
section 12.1.1.

Thank you,
Miki

---

From: Miki HASEBE <[email-masked]>
Date: Tue, 11 Sep 2007 17:25:58 +0900

Hi,

The answer is inline.

> without sending of any message explicitly, does it?

Yes, it does.

> wonder if you can make it clearer in this draft?

As described in section 8.2.6.2 of RFC3261,
UAS MUST add a To tag to the response other than 100.
Furthermore, as described in section 12.1.1,
UAS MUST add a Contact header to the response if it constructs a dialog.
 (A 1xx without To tag is taken into consideration only for backwards
  compatibility with RFC2543. See section 12.1.2.)
I guess that means it is not so much "there're two categories of 1xx
response" as "there're 100 and 1xx other than 100 (101-199)".

I would like to know which description you think should be clarified.
Do you mean that Contact header in page 162 of RFC3261 should be
essentially divided into 100 and 101-199?
If it is correct, it is a minor improvement on the description of
RFC3261, but I think that it's outside scope of this draft since
it is not concerned with the sequence in race condition.
Do I understand your point correctly?

Thank you,
Miki

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Tue, 11 Sep 2007 16:38:01 +0800

Mike,

Thanks for your quick reply.

The point I want some clarification is

In the draft Page 9

Early (Ear):  The early dialog is established by sending or receiving
      a provisional response with To tag.

Here looks like as long as UA send or receive a  provisional response
with to tag , the early dialog is established.
Actually as you said, "as described in section 12.1.1, UAS MUST add a
Contact header to the response if it constructs a dialog."
So if UA sends/receives a provisional response with to tag , but without
Contact header , which I think is valid, it should be stay in
Preparative state.

So I just would like this draft add a few words here to make it clearer:

Early (Ear):  The early dialog is established by sending or receiving
      a provisional response with To tag and Contact header.

What do you think?

Thanks

Regards,
-Rockson

-----Original Message-----
From: Miki HASEBE [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 4:26 PM
To: Rockson Li (zhengyli)
Cc: [email-masked]; Paul Kyzivat (pkyzivat);

Hi,

The answer is inline.

"Rockson Li (zhengyli)" <[email-masked]> wrote:

> the early dialog would be terminated locally, without sending of any 
> message explicitly, does it?

Yes, it does.

> For question 2 on 1xx resp establishing early dialog, Yes, as you 
> said, "in page 162 of RFC3261, a Contact header of 1xx is "o"", but 
> how does it prove it only applies to 100, Since from the table, it 
> clearly shows any 1xx resp can take contact header optionally.
> 
> I think there're two categories of 1xx response, which intends to 
> create early dialog and which not.
> For those who intends to create early dialog as said in RFC3261 
> "12.1.1 UAS behavior", must have Contact header.

As described in section 8.2.6.2 of RFC3261, UAS MUST add a To tag to the
response other than 100.
Furthermore, as described in section 12.1.1, UAS MUST add a Contact
header to the response if it constructs a dialog.
 (A 1xx without To tag is taken into consideration only for backwards
  compatibility with RFC2543. See section 12.1.2.) I guess that means it
is not so much "there're two categories of 1xx response" as "there're
100 and 1xx other than 100 (101-199)".

I would like to know which description you think should be clarified.
Do you mean that Contact header in page 162 of RFC3261 should be
essentially divided into 100 and 101-199?
If it is correct, it is a minor improvement on the description of
RFC3261, but I think that it's outside scope of this draft since it is
not concerned with the sequence in race condition.
Do I understand your point correctly?

Thank you,
Miki

> > 1. BYE sent, 2. CANCEL sent, 3, session terminated locally, 4. 
> > dialog destroyed locally ?
> 

> other 1xxs are also included in "such as" which is described in "such 
> as a 2xx to INVITE".
> (Probably, in page 162 of RFC3261, a Contact header of 1xx is "o" 
> which shows  only that a 100 does not contain it.) A Contact header is

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 11 Sep 2007 09:25:00 -0400

There is no reason to mention the requirement of the Contact within the
Early definition.  The early dialog is created by presence of To tag
within the non 100 provisional response.  The lack of Contact does not
preempt it being an early dialog; it instead implies rfc2543 compliance
instead of rfc3261 compliance.

As mentioned within the rfc3261 section 12.1.1 quote, rfc3261 requires
the Contact (even if rfc2543 did not).

> From: Rockson Li (zhengyli) [mailto:[email-masked]] 
> Sent: Tuesday, September 11, 2007 4:38 AM
> To: Miki HASEBE
> Cc: Paul Kyzivat (pkyzivat); [email-masked]
> Subject: [Sipping] RE: another two questions 
> ondraft-ietf-sipping-race-examples-04
> 
> Mike,
> 
> Here looks like as long as UA send or receive a  provisional 
> response with to tag , the early dialog is established.
> Actually as you said, "as described in section 12.1.1, UAS 
> MUST add a Contact header to the response if it constructs a dialog."
> So if UA sends/receives a provisional response with to tag , 
> but without Contact header , which I think is valid, it 
> should be stay in Preparative state.
> 
> As described in section 8.2.6.2 of RFC3261, UAS MUST add a To 
> tag to the response other than 100.
> Furthermore, as described in section 12.1.1, UAS MUST add a 
> Contact header to the response if it constructs a dialog.
>   compatibility with RFC2543. See section 12.1.2.) I guess 
> that means it is not so much "there're two categories of 1xx 
> Do you mean that Contact header in page 162 of RFC3261 should 
> be essentially divided into 100 and 101-199?
> If it is correct, it is a minor improvement on the 
> description of RFC3261, but I think that it's outside scope 
> of this draft since it is not concerned with the sequence in 
> race condition.

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Tue, 11 Sep 2007 23:18:59 +0800

Brett,

Remote target which is derived from 1xx or 200's Contact  header is a
mandatory component of dialog.
So if non-100 provisional response could create early dialog, how could
UA construct the mid-early-dialog request?
Suppose 3261 compliant UA receives an 180 response with to tag and
record-router header but without Contact,
What would be put as the Request URI?

Can you give me an example please?

Thanks

Regards,
-Rockson

-----Original Message-----
From: Brett Tate [mailto:[email-masked]] 
Sent: Tuesday, September 11, 2007 9:25 PM
To: Rockson Li (zhengyli)
Cc: [email-masked]
Subject: RE: [Sipping] RE: another two questions

> So if UA sends/receives a provisional response with to tag , but 
> without Contact header , which I think is valid, it should be stay in 
> Preparative state.
> 
> As described in section 8.2.6.2 of RFC3261, UAS MUST add a To tag to 
> the response other than 100.
>   compatibility with RFC2543. See section 12.1.2.) I guess that means 
> it is not so much "there're two categories of 1xx response" as 
> "there're 100 and 1xx other than 100 (101-199)".
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Sep 2007 11:50:49 -0400

> Can you give me an example please?

I think the point is that it still is an early dialog, but an incomplete 
one. As a result of being incomplete there are things that are not 
possible. In particular it is impossible to send a mid-dialog request.

The existing state machines still apply except that some of the 
transitions aren't possible.

Of course this *could* be singled out as a separate state. The question 
is whether it is worth the trouble to do so.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 11 Sep 2007 13:46:24 -0400

As mentioned within the rfc3261 section 12.1.1 quote, rfc3261 requires
the Contact (even if rfc2543 did not).  Thus per rfc3261, it is abnormal
behavior for Contact to not be present.  

However concerning aspects of your question, rfc2543 section 11.3
indicates that the request-uri would be the To.  However since it is
abnormal behavior per rfc3261, a device not sending the Contact is
basically at the mercy of however a rfc3261 compliant device desires to
handle it.

If I recall correctly, the complications added by record-routing was one
of the many reasons why the Contact started being mandatory around
bis-01.  And the authors and working group considered it a bug within
rfc2543; thus no reason for rfc3261 to remain backward compatible with
rfc2543 concerning the issue.

> Sent: Tuesday, September 11, 2007 11:19 AM
> To: Brett Tate
> Cc: [email-masked]
> Remote target which is derived from 1xx or 200's Contact  
> header is a mandatory component of dialog.
> So if non-100 provisional response could create early dialog, 
> how could UA construct the mid-early-dialog request?
> Suppose 3261 compliant UA receives an 180 response with to 
> tag and record-router header but without Contact, What would 
> be put as the Request URI?
> 
> There is no reason to mention the requirement of the Contact 
> within the Early definition.  The early dialog is created by 
> presence of To tag within the non 100 provisional response.  
> The lack of Contact does not preempt it being an early 
> dialog; it instead implies rfc2543 compliance instead of 
> rfc3261 compliance.
> 
> As mentioned within the rfc3261 section 12.1.1 quote, rfc3261 
> requires the Contact (even if rfc2543 did not).
> 
>

---

From: Miki HASEBE <[email-masked]>
Date: Wed, 12 Sep 2007 14:49:44 +0900

>       a provisional response with To tag and Contact header.

I get another point concerning it.
It doesn't seem enough to mention only "To tag" here.

According to section 17.2.1, the insertion of tags in the To header field
is SHOULD NOT and is not MUST NOT. However, early dialog will not be
established even if an UA sends or receives 100 with To tag.
So, I think that the following description is accurate because the 
establishment of early dialog is not decided only by the existence of To tag,
but it is decided by the provisional response except 100.

Early (Ear):  The early dialog is established by sending or receiving
      a provisional response except 100 Trying.

Additionally, I point out relating to the backwards compatibility with RFC2543.
According to description of RFC3261,
even if UAC receives a provisional response without To tag,
UAC should consider the tag has a value of null. (12.1.2 of RFC3261)
And even in this case, UAC makes an early dialog for the provisional
response.

Thank you,
Miki

---

From: Miki HASEBE <[email-masked]>
Date: Wed, 12 Sep 2007 14:51:27 +0900

I completely agree with you.

Miki

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Wed, 12 Sep 2007 15:05:50 +0800

Thanks Miki on your modification of the draft. It looks fine to me now.

OK, after Brett and your comments.

I finally comes to me a new understanding of RFC3261.

12.1.1 UAS behavior

   order of those values.

Here "response that establish a dialog" includes 101 ~ 199 and 2xx
response,
So they all MUST contain Contact header.

Am I correct this time?

It's a little unexpected to me, my initial thougts is
101 - 199 response with to tag might or might not establish early dialog
If UAS intends to setup an early dialog, it includes a Contact header.
Otherwise not....

Looks like it's not the case.

Thanks

Regards,
-Rockson

-----Original Message-----
From: Miki HASEBE [mailto:[email-masked]] 
Sent: Wednesday, September 12, 2007 1:50 PM
To: Rockson Li (zhengyli)
Cc: [email-masked]; Paul Kyzivat (pkyzivat);

According to section 17.2.1, the insertion of tags in the To header
field is SHOULD NOT and is not MUST NOT. However, early dialog will not
be established even if an UA sends or receives 100 with To tag.
So, I think that the following description is accurate because the
establishment of early dialog is not decided only by the existence of To
tag, but it is decided by the provisional response except 100.

Additionally, I point out relating to the backwards compatibility with
RFC2543.
According to description of RFC3261,
even if UAC receives a provisional response without To tag, UAC should
consider the tag has a value of null. (12.1.2 of RFC3261) And even in
this case, UAC makes an early dialog for the provisional response.

Thank you,
Miki

> > So for question 1 on "mortal early dialog", I think it probably 
> > means the early dialog would be terminated locally, without sending 
> > of any message explicitly, does it?
> 
> Yes, it does.
> 

> > Here, when two or more early dialog is established by fork, the 
> > early dialog which did not receive 2xx is called "mortal early
state".

> > If the INVITE transaction is completed in UAC, all other early 
> > dialog which have not received 2xx will be terminated.
> > 

> > >    When a UAS responds to a request with a response that 
> > > establishes
> a
> > >    header field values from the request into the response 
> > > (including
> > the

> > > diagram
> > other 1xxs are also included in "such as" which is described in 
> > "such as a 2xx to INVITE".