[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:christer.holmberg at ericsson.com]
Sent: Friday, February 29, 2008 3:49 AM
To: Paul Kyzivat (pkyzivat); Rockson Li (zhengyli)
Cc: sip at ietf.org
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
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 28. helmikuuta 2008 19:47
> To: Rockson Li (zhengyli)
> Cc: Christer Holmberg; sip at ietf.org
> 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.
>
> 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
>
> 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
> >
> >
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip