Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not?

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Thu, 28 Feb 2008 13:39:26 +0800

Paul , Christer and all,
 
I am following the email thread as in subject above
http://www.ietf.org/mail-archive/web/sip/current/msg19322.html
 
However, I do not find the definite answer to Christer's question,
Do we have the answer now?
 
Thanks a lot

Regards,
Rockson Li 

Cisco R&D Center, Shanghai, PRC

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 28 Feb 2008 09:45:40 +0100

Hi,
 
I don't think anything has happened since Paul said he agrees :)
 
I guess this is one thing, similar to the PRACK 488 (see other thread), that we need to try to figure out how to document (and, of course, what to document).
 
Regards,
 
Christer

________________________________

From: Rockson Li (zhengyli) [mailto:[email-masked]]
Sent: Thu 28/02/2008 06:39
To: Paul Kyzivat (pkyzivat); Christer Holmberg
Cc: [email-masked]
Subject: Re: [Sip] Contact header in 1xx responses/updates remote target or not?

Paul , Christer and all,

 
Thanks a lot

Regards,
Rockson Li

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 28 Feb 2008 12:46:35 -0500

No, I don't think we have an answer, though I do have an opinion. :-)

Are you asking about whether the contact may be omitted? Or if it may be 
changed?

AFAIK there is nothing normative that *forbids* the contact from being 
changed in subsequent provisional responses. But doing so is *asking* 
for trouble, so you shouldn't do it. Perhaps you could get away with it 
in a *reliable* provisional, but then you would still have a bunch of 
messy cases. The likelihood of it working is slim. Doing it with 
*unreliable* provisionals is going to cause trouble because they can be 
lost. Even with reliable provisionals, you will have to be prepared to 
receive on both addresses for some period of time.

It seems clear that a contact may be omitted in a 100, since it is hop 
by hop, and presumably must be omitted in the 100 responses from 
proxies. Some other 1xx responses may be returned by proxies (notably 
181) and presumably they should also not contain a contact in those cases.

A 1xx that establishes an early dialog must contain a contact or else 
you really don't have a dialog. I think it is ambiguous whether:
- the first 1xx with a particular to-tag *does* establish an early
   dialog and so *must* contain a contact,

- OR a 1xx with a new to-tag, but without a contact, simply doesn't
   establish a dialog, but is legal.

I would split the difference and say that the UAS MUST include a contact 
in the first 1xx it returns with a particular to-tag, but a UAC should 
accept a 1xx with new to-tag and without a contact and simply treat it 
as not establishing an early dialog. (Don't establish the dialog until 
you get enough info to do so.)

	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 28 Feb 2008 20:49:11 +0100

Hi,

I agree with Paul's conclusion. But, I still think that is somethin that
we should somehow document and clarify. This is a common reason for
interop problems, so just agree on a mailing list and leave it there is
not a good thing to do.

IF (To-tag && Contact) THEN dialog 

And, it IS allowed to update the Contact in subsequence provisional
responses. But, as Paul said: it is asking for trouble, so it should not
be done unless you have a really good reason for it.

I also think that updating the Contact in a re-INVITE/UPDATE is asking
for trouble. At least you also there need to be prepared to receive
requests on both the new and old contact for a period of time.

Regards,

Christer

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 28. helmikuuta 2008 19:47
> To: Rockson Li (zhengyli)
> Cc: Christer Holmberg; [email-masked]
> Are you asking about whether the contact may be omitted? Or 
> if it may be changed?
> 
> AFAIK there is nothing normative that *forbids* the contact 
> from being changed in subsequent provisional responses. But 
> doing so is *asking* for trouble, so you shouldn't do it. 
> Perhaps you could get away with it in a *reliable* 
> provisional, but then you would still have a bunch of messy 
> cases. The likelihood of it working is slim. Doing it with
> *unreliable* provisionals is going to cause trouble because 
> they can be lost. Even with reliable provisionals, you will 
> have to be prepared to receive on both addresses for some 
> period of time.
> 
> It seems clear that a contact may be omitted in a 100, since 
> it is hop by hop, and presumably must be omitted in the 100 
> responses from proxies. Some other 1xx responses may be 
> returned by proxies (notably
> A 1xx that establishes an early dialog must contain a contact 
> or else you really don't have a dialog. I think it is 
> ambiguous whether:
> I would split the difference and say that the UAS MUST 
> include a contact in the first 1xx it returns with a 
> particular to-tag, but a UAC should accept a 1xx with new 
> to-tag and without a contact and simply treat it as not 
> establishing an early dialog. (Don't establish the dialog 
> until you get enough info to do so.)
> 
> 	Paul
> 
> > However, I do not find the definite answer to Christer's 
> question, Do 
> > we have the answer now?
> >  
> > Thanks a lot
> > 
> > Regards,
> > Rockson Li
> >

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Fri, 29 Feb 2008 13:15:27 +0800

Paul and Christer,

As I understand the contact/remote-target update is 
remote-target is only set when dialog created , there's no way of
changing it after dialog(early of confirmed) establishment except
target-refresh req(re-inv/update)
the reason is as follows,

in RFC3261 13.2.2.1 1xx Response
   If a provisional response
   has a tag in the To field, and if the dialog ID of the response does
   not match an existing dialog, one is constructed using the procedures
   defined in Section 12.1.2.  

which means the contact would only be set  in UAC upon dialog creation,
even later the non-100 1xx response(wether reliable or not) 
change contact, the dialog state would not change as above.
similar meaning is stated in
http://www.ietf.org/mail-archive/web/sip/current/msg07893.html

and here only says to tag is the sole criteria for early-dialog
construction, not contact header mentioned at all.
similar discussion at
http://www.ietf.org/mail-archive/web/sipping/current/msg14510.html

if dialog-creating-non-100-1xx does not have contact, looks like the
it's RFC2543-compliant UA and remote-target of the UAC should be To as
per RFC2543 section 11.3
check Brette's option here
http://www.ietf.org/mail-archive/web/sipping/current/msg14514.html

When dialog transitioned from early to confirmed.

sec 13.2.2.4 2xx Responses
   If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.  Otherwise, a new dialog in the "confirmed" state MUST be
   constructed using the procedures of Section 12.1.2.

      Note that the *only* piece of state that is recomputed is the
route
      set.  Other pieces of state such as the highest sequence numbers
      (remote and local) sent within the dialog are not recomputed.  The
      route set only is recomputed for backwards compatibility.  RFC
      2543 did not mandate mirroring of the Record-Route header field in
      a 1xx, only 2xx.  However, we cannot update the entire state of
      the dialog, since mid-dialog requests may have been sent within
      the early dialog, modifying the sequence numbers, for example.

So only route set could be changed, remote-target just remains as the
same as early dialog, even 200 change the contact.

comments?

Regards,
-Rockson

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: Friday, February 29, 2008 3:49 AM
To: Paul Kyzivat (pkyzivat); Rockson Li (zhengyli)
Cc: [email-masked]
Subject: RE: [Sip] Contact header in 1xx responses/updates remote target
or not?

Hi,

Regards,

Christer

> Are you asking about whether the contact may be omitted? Or if it may 
> be changed?
> 

> for trouble, so you shouldn't do it.
> Perhaps you could get away with it in a *reliable* provisional, but 
> then you would still have a bunch of messy cases. The likelihood of it

> working is slim. Doing it with
> *unreliable* provisionals is going to cause trouble because they can 
> be lost. Even with reliable provisionals, you will have to be prepared

> to receive on both addresses for some period of time.
> 

> I would split the difference and say that the UAS MUST include a 
> contact in the first 1xx it returns with a particular to-tag, but a 
> UAC should accept a 1xx with new to-tag and without a contact and 
> simply treat it as not establishing an early dialog. (Don't establish 
> the dialog until you get enough info to do so.)
> 
> 	Paul
>

---

From: [email-masked]
Date: Fri, 29 Feb 2008 22:26:56 -0500

From: Paul Kyzivat <[email-masked]>

I'd say that it does create a dialog, but it's an anomalous dialog in
that you can't send any requests to it.  (Though it's unlikely that
you'd want to.)  But you might well get a final response from the
dialog, and you could get media from it.

I think it's the fact that the UAC is unlikely to send a request until
the dialog becomes confirmed is why we haven't worried about this case
much.

Dale