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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Mar 2008 11:54:46 -0500

[email-masked] wrote:
>    From: Paul Kyzivat <[email-masked]>
> 
>    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.)
> 
> 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.

What is so unlikely about this?

The UAC may want to send BYE (as opposed to CANCEL) because it doesn't 
want *this* one.

The Contact is one of the attributes of dialog state. AFAIK we don't 
have the notion of a dialog that exists but for which some state is 
unknown.

Its really a matter of which poison you want here.

	Paul
_______________________________________________
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: Mon, 3 Mar 2008 22:23:56 +0100

Hi,

I don't understand what "dialog without state is" either. The Contact is
part of the dialog identifier, so if there ain't no Contact there ain't
no dialog :)

Regards,

Chrrister 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> Sent: 3. maaliskuuta 2008 18:55
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sip] Contact header in 1xx responses/updates 
> remote target or not?
> 
> 
> 
> The UAC may want to send BYE (as opposed to CANCEL) because 
> it doesn't want *this* one.
> 
> The Contact is one of the attributes of dialog state. AFAIK 
> we don't have the notion of a dialog that exists but for 
> which some state is unknown.
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 03 Mar 2008 19:08:16 -0500

> part of the dialog identifier, so if there ain't no Contact there ain't

Its not part of the dialog-id. That consists of the Call-ID, from-tag 
and to-tag.

But still it is a part of the basic dialog state, along with the route-set.

	Paul

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Tue, 4 Mar 2008 10:22:59 +0800

Hi guys,

Any comments on my previous thoughts are appreciated.

Thanks

Regards,
-Rockson

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

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,

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

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 28. helmikuuta 2008 19:47
> To: Rockson Li (zhengyli)
> Cc: Christer Holmberg; [email-masked]
> Subject: Re: [Sip] Contact header in 1xx responses/updates remote 
> target or not?
> 
> 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.
> 
> 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
> 
> Rockson Li (zhengyli) wrote:
> > 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
> > 
> >  
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 4 Mar 2008 07:59:05 +0100

Hi,

>>I don't understand what "dialog without state is" either. The Contact is part of the dialog identifier, so if there ain't no >>Contact there ain't no dialog :)
>

Correct. That's what I meant.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Mar 2008 10:35:34 -0500

> http://www.ietf.org/mail-archive/web/sip/current/msg07893.html

I don't find that the above mail message says anything about what to do 
with the remote target (Contact) if it changes.

> construction, not contact header mentioned at all.

It only discusses the criteria for matching the request to a dialog. So 
you wouldn't have two dialogs with the same from-tag/to-tag/callid and 
different contacts.

> http://www.ietf.org/mail-archive/web/sipping/current/msg14510.html

Its been a long time since I read 2543, and I don't have time to do it 
now. It may indeed be the case that some behavior is required for 2543 
compatibility. But AFAIK it is rare to find a 2543 implementation these 
days, so this may not be an important concern. It seems that 3261 didn't 
call out specific behavior wrt the Contact for 2543 compatibility in the 
same way that it called for specific behavior re R-R. So it seems we 
have little guidance here.

> http://www.ietf.org/mail-archive/web/sipping/current/msg14514.html

In that mail Brett seems to say that this was considered a bug in 2543, 
so we shouldn't necessarily be striving for compatibility with it.

>       the early dialog, modifying the sequence numbers, for example.

I find the above text to be problematic and internally inconsistent. The 
initial sentence conflicts with the rest. The sequence numbers are 
updated all along, on each request. The local sequence number isn't 
updated on a response because it is updated when the request is sent. 
And the remote sequence number isn't updated upon receiving a response 
because it don't contain a remote sequence number.

So while the first statement above seems to say that the local/remote 
target may not be updated based on a subsequent response, I'm not sure 
to what extent to trust that paragraph. This seems more on the order of 
a bug.

Ultimately we need to deal with what makes sense and works. When things 
are not as you like in a response its hard to complain about them. You 
pretty much have to cope. Otherwise your only choices are to send a BYE 
or else just drop the transaction and let it time out. In this case 
sending a BYE may well not work either - which remote target would you 
send it too?

I think we can recommend that the Contacts not be changed until after a 
confirmed dialog. But when confronted with a request that does change 
it, interoperability is probably enhanced by believing it. Are things 
likely to work better if you ignore it??? Presumably the other end put 
the new value in for some reason. Probably because the old address won't 
work any more.

	Paul

---

From: [email-masked]
Date: Tue, 4 Mar 2008 23:25:00 -0500

Interesting -- I'd never thought of sending BYE on an early dialog.
But clearly it's possible and clearly it terminates the dialog.  I
wonder if any phones do that?

I've tried thinking about this some more, and I am beginning to
believe that there is no situation where there is a functional
difference between the two strategies, that is, not creating an early
dialog when a 1xx without Contact arrives, and creating an early
dialog without a recorded Contact from such a 1xx.  So it probably
doesn't matter which choice one makes.

Dale

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 6 Mar 2008 02:34:46 -0800

> wonder if any phones do that?

Whilst not particularly common, it is one approach used to prevent early
media processing becoming too complex.  If a UA already has negotiated
early media on one early dialog, and then a second early dialog is
formed with an SDP answer (reliably delivered, of course), it is
sometimes easier/desirable/less bug-prone to send a BYE on one of the
early dialogs.

> doesn't matter which choice one makes.

Quite.  If a dialog forms in a forest [0], but nobody can send a message
over it, does it really exist?

Michael

[0] http://en.wikipedia.org/wiki/If_a_tree_falls_in_a_forest

---

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 6 Mar 2008 12:11:00 +0100

Hi, 

>>difference between the two strategies, that is, not 
>>creating an early dialog when a 1xx without Contact arrives, and
creating an early 
>Quite.  If a dialog forms in a forest [0], but nobody can 
>send a message over it, does it really exist?

Well, I think there could be a difference, if it is assumed that the 18x
is supposed to trigger some actions (related to resources, security, NAT
traversal, media, whatever...).

If no Contact is considered a protocol error one would simply ignore it.

If NOT considered a protocol error, one could say that it is an error to
not start triggering those actions.

Regards,

Christer

---

From: "Michael Procter" <[email-masked]>
Date: Thu, 6 Mar 2008 05:09:34 -0800

> traversal, media, whatever...).

True.  And any intermediate device that wishes to take action (e.g.
refresh NAT bindings or whatever) can continue to do so, but that still
doesn't make it a useful dialog.

> not start triggering those actions.

Or you could pretend the packet got lost in the network ;-)  There is no
contact, so you can't send a PRACK.  The remote end can't know for sure
that the packet ever got to you.

I am not saying that you MUST ignore it, or that you MUST NOT ignore it.
I simply agree with Dale's assessment that *from a SIP perspective*, any
creation or otherwise of an early dialog doesn't really matter.  An
implementor may choose the most appropriate action for their scenario,
which may depend on non-SIP considerations (such as resources, security,
NAT traversal, media, whatever...).

Of course, whether taking any resource-related action on receipt of such
a 1xx response is prudent (when you can't terminate the dialog at will),
will depend very much on your specific application and operating
environment.  Sometimes it will be wise, and sometimes it won't.

Regards,

Michael

---

From: "Rockson Li (zhengyli)" <[email-masked]>
Date: Thu, 6 Mar 2008 21:19:48 +0800

Paul, 

appreciate your comments :-) , see my comments inline.

Thanks
Regards,
-Rockson 

-----Original Message-----
From: Paul Kyzivat (pkyzivat) 
Sent: Tuesday, March 04, 2008 11:36 PM
To: Rockson Li (zhengyli)
Cc: Christer Holmberg; [email-masked]
Subject: Re: [Sip] Contact header in 1xx responses/updates remote target
or not?

Rockson Li (zhengyli) wrote:
> Subject: RE: [Sip] Contact header in 1xx responses/updates remote 
> target or not?
> 
> Paul and Christer,
> 
> 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.

[Rockson] as in Jonathan's mail,  please note the following sentence,
"Note that this means that the state is set only upon creation, which
means the first 1xx response. THis is modified by the speific behavior
for INVITE, from 13.2.2.4", 
since remote-target is party of dialog state, so it means it only set
upon dialog(either early or confirmed) creattion and not updated
anymore.

[Rockson] I think here 3261 just uses sequence number as an example, it
just want say dialog state might be updated in early dialog,so it cannot
be reset when it transitioned to confirmed.

[Rockson] another bug here? 3261 here explains its meaning with emphasis
in terms of *only* , cannot be trusted?
If it's cannot be dependable and customer and user complains based on
the paragraph above, how am I supposed to do? 
give him/her this discussion mail ? :-( 

	Paul

> Subject: RE: [Sip] Contact header in 1xx responses/updates remote 
> target or not?
> 
> 
> 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.
> 
> 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.
>

---

From: Robert Sparks <[email-masked]>
Date: Thu, 6 Mar 2008 09:28:00 -0600

I haven't been able to follow this thread as closely as I would like  
to - apologies.

I would like to bring one question we stumbled over previously back  
into the conversation
if its not already here (I get the impression you've zoomed in on an  
initial invite).

Given the conversation so far, do we have a good answer yet for the  
question here:

http://www.ietf.org/proceedings/06jul/slides/sipping-8/sld4.htm

(you can replace the subscription usage messages with INVITEs if the  
mixed-usage nature
of that graph bothers you and the question remains the same).

RjS

On Mar 6, 2008, at 7:19 AM, Rockson Li (zhengyli) wrote:

> target