Subject: [sipcore] Changing contact/remote target in target refresh response

From: "Taisto Qvist XX" <[email-masked]>
Date: Mon, 2 Nov 2009 15:57:41 +0100

Hi folks, 
 
I am in a discussion with a firewall provider, regarding the "legality"
for a UAS 
to use different Contact: uri's in 1xx and 2xx for the same
transaction/dialog.
 
I claim that you MUST use the same Contact in the 2xx as was sent the
1xx. 
Unfortunately I cant give him an explicit reference, since there is
none(afaik?)

Instead I must indicate chapters that indicate that UAS must initialize
dialog state 
on reception of the 1xx, and that on reception of 2xx, the only thing
that is recomputed, 
is the routeset. The firewall provider is not convinced.
 
Also the text in 3261, 12.1.1 indicates(?) that the Contact should be
the same in 2xx and 1xx.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
order of those values.  The UAS MUST add a Contact header field to
the response.  The Contact header field contains an address where the
UAS would like to be contacted for subsequent requests in the dialog
(which includes the ACK for a 2xx response in the case of an INVITE).
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 
Now to my question, or sort of...

Is a target refresh used by the UAC, and implicit target refresh
possibility also for the UAS?
In other words, is the response to a target refresh request, a "response
target refresh"?

Can the UAS add a new Contact in the 2xx response to a target refresh,
and assume that the UAC 
updates its remote target? I've read Gonzalo Camarillo's draft, but it
doesnt really mention
this scenario.

If the UAS can change his Contact, then I've become puzzled on what I
should add in the final 2xx 
to an initial INVITE, if both sides(uas/uac) have updated their contacts
during an UPDATE-target 
refresh in the early dialog.

The flow would be
1) INVITE   from A -> B  (contact:a1)

2) 18x      from B -> A  (contact:b1)
+ prack, early media, go figure...

3) UPDATE   from A -> B  (contact:a2)

4) 2xx(UPD) from B -> A  (contact:b2)               << "target refresh
response"

5) 2xx(INV) from B -> A  (contact......b2 or b1?)

6) ACK-time..remote target is b2...

If the Contact "SHOULD/MUST" be the same as 1xx, then b1 is the answer,
but at the same time, 
the ACK must be sent to b2....

Any feedback you can give me would be much appreciated. 

Regards
Taisto Qvist
IP-Solutions

---

From: Jeroen van Bemmel <[email-masked]>
Date: Mon, 02 Nov 2009 22:36:16 +0100

Hi Taisto,

My question would be: what is the purpose of using different values in 
the Contact header like this? It certainly complicates things, and does 
not help interoperability.
Given your reference to a "firewall provider", I'm guessing it has 
something to do with security?

What is changing between Contact values, the IP address? port? some 
'magic' tag?

Contact is optional in 1xx responses (except in case of 100rel), and in 
practice I believe you will find that most UAS use the same value in 1xx 
and 2xx responses to a given INVITE. There's no law against using 
different values AFAIK, so in your step 5 the UAS could even use "b3" as 
a value. The UAC should simply send its ACK to the contact from the 2xx 
response to INVITE.

Regards,
Jeroen

Taisto Qvist XX wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>
>

---

From: "Taisto Qvist XX" <[email-masked]>
Date: Tue, 3 Nov 2009 09:49:37 +0100

Hi Jeroen, 

I know the scenario is a bit weird, but thats we I need more experts
telling the
firewall guys that they cant behave like this. My scenario-description
is a bit
simplified, but think of it as a bad fw-alg that manages to do
nat-traversal
logic for the contact in 2xx, but forgets to do so on the 1xx.

Despite the scenarios possible...weirdess, I really need a clarification
to
wether a target refresh request is really just for refreshing the UAC's
Contact, or if it allowes the UAS to do the same.

One thing puzzles me...you're saying that the Contact is NOT mandatory??

My reading of the rfc says that it IS mandatory, even though the "MUST"
is
spread over three different places.

First we have:

8.2.6.2

   in the response MUST equal that of the request.  However, if the To
   header field in the request did not contain a tag, the URI in the To
   header field in the response MUST equal the URI in the To header
   field; additionally, the UAS MUST add a tag to the To header field in
   the response (with the exception of the 100 (Trying) response, in
   which a tag MAY be present). 

So I MUST add a to-tag to all my 1xx, except 100 Trying, where it's
optional.

Secondly:
12.1 Creation of a Dialog

   Dialogs are created through the generation of non-failure responses
   to requests with specific methods.  Within this specification, only
   2xx and 101-199 responses with a To tag, where the request was
   INVITE, will establish a dialog.  A dialog established by a non-final
   response to a request is in the "early" state and it is called an
   early dialog.  

and then finally:

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.  The Contact header field contains an address where the
   UAS would like to be contacted for subsequent requests in the dialog
   (which includes the ACK for a 2xx response in the case of an INVITE).

So this means that 1) I MUST add a to-tag, 2) This creates a dialog, and
3) that means I MUST add Contact. 

Is that not a correct interpretation, for INVITE??

The final reference is also the place where, at least with a little
imagination, 
you could interpret the text in third paranthesis as to say "you must
put the 
same contact in 1xx as in 2xx, since it should be used for ACK".

Regards
Taisto Qvist

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: den 2 november 2009 22:36
To: Taisto Qvist XX
Cc: [email-masked]
Subject: Re: [sipcore] Changing contact/remote target in target refresh
response

Hi Taisto,

Regards,
Jeroen

Taisto Qvist XX wrote:
> Instead I must indicate chapters that indicate that UAS must 
> initialize dialog state on reception of the 1xx, and that on reception

> of 2xx, the only thing that is recomputed, is the routeset. The 
> firewall provider is not convinced.
>  
> order of those values.  The UAS MUST add a Contact header field to the

> response.  The Contact header field contains an address where the UAS 
> would like to be contacted for subsequent requests in the dialog 
> In other words, is the response to a target refresh request, a 
> "response target refresh"?
>

> and assume that the UAC updates its remote target? I've read Gonzalo 
> Camarillo's draft, but it doesnt really mention this scenario.
>
> should add in the final 2xx to an initial INVITE, if both 
> sides(uas/uac) have updated their contacts during an UPDATE-target 
> If the Contact "SHOULD/MUST" be the same as 1xx, then b1 is the 
> answer, but at the same time, the ACK must be sent to b2....
>

---

From: Jeroen van Bemmel <[email-masked]>
Date: Tue, 03 Nov 2009 21:22:55 +0100

Hi Taisto,

Refer to table 2 in RFC3261 (section 20.1), where it says "o" for 
Contact in 1xx responses. I guess the reasoning is that the 1xx is 
unreliable and will always be followed by a 2xx response anyway, such 
that it is sufficient to include the Contact only in the 2xx. Obviously 
a 100rel scenario is an exception to this rule.

Some other relevant references:
12.2.1.1: "A UAC SHOULD include a Contact header field in any target 
refresh requests within a dialog, and unless there is a need to change 
it, the URI SHOULD be the same as used in previous requests within the 
dialog."

12.2.1.2 "When a UAC receives a 2xx response to a target refresh 
request, it MUST replace the dialog's remote target URI with the URI 
from the Contact header field in that response, if present."

In other words: the UAS can refresh its target too (but like for the 
UAC, even if RFC3261 doesn't spell it out, it SHOULD use the same URI 
unless there is a need to change it)

Regards,
Jeroen

Taisto Qvist XX wrote:
>> I am in a discussion with a firewall provider, regarding the
>>     
> "legality"
>   
>> for a UAS

---

From: "Taisto Qvist XX" <[email-masked]>
Date: Wed, 4 Nov 2009 09:53:05 +0100

Hi, 

Regarding the table you refer to, I see that as generic rules for
headers, 
and that additional rules apply in some scenarios. 

Anyway, it still doesnt change the three MUSTs i referred to. 
They clearly say that IF I create a dialog, I MUST, without doubt, 
add Contact, RR, etc. And since I MUST add the tag in all 1xx, I also
create a dialog, etc, etc. 

I dont see how those three rules can be disregarded, and I would really
like
more people to comment on this.

The reference in 12.2.1.2 had slipped my mind, and thats annoying. It
clearly says
parts of what I wanted. A target-refresh is..."bi-directional", both
sides can
change their contact.

But neither reference is actually valid in the scenario i described,
since it 
is NOT an indialog request. 

I am referring to the 1xx and 2xx responses of an _initial_ INVITE. Even
if it 
would be as you say, that the contact is not mandatory in 1xx, it IS
legal to send
it, and there is no clear text saying that I cant, or MUST NOT change it
when I
send a 2xx. (apart from the description that UAC should only update
route-set on
reception of 2xx)

The UAS will initialize its state on receiving the first dialog-creating
response, 
so if they get the 1xx, that's the remote-target that will be used on
the ACK, 
unless we add additional target-refreshes indialog with UPDATE.

So what I am after is a simple rule describing what the Contact should
be in 2xx, 
for an initial when we dont have any target-refreshes complicating the
issue. 
I think that it should be more clearly stated that it MUST be the same
as in the 1xx, 
if you sent a contact in 1xx(if we accept that its not mandatory, which
I think it is).

For a scenario WITH target-refresh of the b-side with UPDATE during the
early dialog, 
it wouldnt hurt with some SHOULD's, or other explanatory text.

I know these are cornercases, but they will, and ARE already creating
interop-problems
so I think its not really interesting why we'd like to do this, but
wether it is allowed, 
and how.

Regards
Taisto Qvist

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: den 3 november 2009 21:23
To: Taisto Qvist XX
Cc: [email-masked]
Subject: Re: [sipcore] Changing contact/remote target in targetrefresh
response

Hi Taisto,

Regards,
Jeroen

Taisto Qvist XX wrote:
> telling the firewall guys that they cant behave like this. My 
> scenario-description is a bit simplified, but think of it as a bad 
> fw-alg that manages to do nat-traversal logic for the contact in 2xx, 
> but forgets to do so on the 1xx.
>
> Despite the scenarios possible...weirdess, I really need a 
> clarification to wether a target refresh request is really just for 
> refreshing the UAC's Contact, or if it allowes the UAS to do the same.
>
> imagination, you could interpret the text in third paranthesis as to 
> say "you must put the same contact in 1xx as in 2xx, since it should 
> be used for ACK".
>
> Regards
> Taisto Qvist
>
>
> Subject: Re: [sipcore] Changing contact/remote target in target 
> refresh response
>
> Hi Taisto,
>

> the Contact header like this? It certainly complicates things, and 
> does not help interoperability.
> Contact is optional in 1xx responses (except in case of 100rel), and 
> in practice I believe you will find that most UAS use the same value 
> in 1xx and 2xx responses to a given INVITE. There's no law against 
> using different values AFAIK, so in your step 5 the UAS could even use

> "b3" as a value. The UAC should simply send its ACK to the contact 
> from the 2xx response to INVITE.
>
> Regards,
> Jeroen
>
> Taisto Qvist XX wrote:
>   
>> Hi folks,
>>  

>> the

---

From: Brett Tate <[email-masked]>
Date: Thu, 5 Nov 2009 09:16:41 -0800

Hi Taisto,

I agree that the rfc3261 text is ambiguous and has some conflicting statements.

The following thread discusses some of the ambiguities:

https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020127.html

In my opinion, a strict interpretation of rfc3261 does not allow INVITE 1xx/2xx's Contact to update the target during call set-up after the dialog has been created.  I'm not sure if the authors actually intended such a restriction; I not aware of vendors actually enforcing such a restriction.

The following is some questions/text from above thread in case someone wants to answer the questions.

Should the remote target be updated per INVITE 2xx's Contact?  If not,
then why is section 13.2.2.4 pointing to section 12.2.1.2?  When I
posted my question, I had thought that it was trying to indicate to
adjust the remote target as if the INVITE 2xx was a re-INVITE 2xx.

Is the following what rfc3261 is attempting to communicate?

1) Dialog forming INVITE 1xx/2xx creates route set based upon
record-route and sets remote target per Contact.

2) Original INVITE's subsequent 101-199 has no impact upon a known
dialog's route set and remote target.

3) Original INVITE's 2xx resets route set per received/missing
record-route and does not set (or update) per Contact.

4) Retargeting (excluding original INVITE) request's 2xx within dialog
allow the remote target to be updated.

---

From: Jeroen van Bemmel <[email-masked]>
Date: Fri, 06 Nov 2009 00:16:09 +0100

Brett,

Even if it's not clearly defined, to me the rule should be simple: 
always update the remote target whenever a valid target refresh 
request/response (1xx or 2xx) containing a Contact header is received 
(with "valid" meaning syntactically correct and in proper dialog 
sequence, matching an existing transaction for responses, and no 
retransmission)

It must be assumed that the peer is communicating its most up-to-date 
value for its Contact address, I see no reason to ignore such updates 
(and I do see how ignoring an updated Contact can cause failures, the 
peer may have obtained a new IP address for example, during the time 
interval it was ringing - e.g. some handset being picked up from a 
docking station with a fixed LAN cable, switching to WiFi)

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 05 Nov 2009 18:43:53 -0500

I agree with Jeroen

Jeroen van Bemmel wrote:
>> In my opinion, a strict interpretation of rfc3261 does not allow 
>> INVITE 1xx/2xx's Contact to update the target during call set-up after 
>> the dialog has been created.  I'm not sure if the authors actually 
>> intended such a restriction; I not aware of vendors actually enforcing 
>> such a restriction.
>>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Nov 2009 08:00:44 +0100

Hi, 

>It must be assumed that the peer is communicating its most 
>up-to-date value for its Contact address, I see no reason to 
>ignore such updates (and I do see how ignoring an updated 
>Contact can cause failures, the peer may have obtained a new 
>IP address for example, during the time interval it was 
>ringing - e.g. some handset being picked up from a docking 
>station with a fixed LAN cable, switching to WiFi)

If you get a new IP address, in most cases I doubt sending a new Contact
header is the only thing you need to do. You probably need to update the
SDP also, and for that we have more strict rules.

In addtion, in order to receive incomming calls, the UE will have to
register the new IP address.

Regards,

Christer

> > In my opinion, a strict interpretation of rfc3261 does not 
> allow INVITE 1xx/2xx's Contact to update the target during 
> call set-up after the dialog has been created.  I'm not sure 
> if the authors actually intended such a restriction; I not 
> aware of vendors actually enforcing such a restriction.
> >
> > The following is some questions/text from above thread in 
> case someone wants to answer the questions.
> >

---

From: "Taisto Qvist XX" <[email-masked]>
Date: Fri, 6 Nov 2009 11:22:46 +0100

Hi, 

Thats why I added/imagined a scenario with both sides sending UPDATEs 
refreshing targets as well as the possibility of sdp-updates.

But thats when I started wondering what on earth should be _required_ by
the UAS
to add as a Contact in the real 2xx to the original, initial INVITE.

Since the rfc says that as UAC you must NOT update remote target on 2xx
to initial
invite, the Contact in 2xx becomes somewhat useless, but it feels like
it should
be more clearly indicated what it should or must be.

On a side note, Im getting the feeling that its a bit fuzzy that when
sending an
inital invite, I update/store the remote target on the first 1xx, but on
target
refresh with invite, on dont update until I get 2xx, right? 
In other words, the Contact in 1xx to a target-refresh is disregarded.
It might
not cause any problems but it seems like its a possibility for
confusion.

I'll add the scenario I first described, since its gotten lost in the
history.

4) 2xx(UPD) from B -> A  (contact:b2)  // "or uas sending its own
UPDATE"

5) 2xx(INV) from B -> A  (contact: b2? b1?)

..and my question was wether the Contact in (5) according to 3261,
"MUST" be b1 or b2, 
since my initial feeling was that it MUST be the same in 1xx and 2xx,
for initial 
INVITE.

Regards
Taisto Qvist

-----Original Message-----
From: Christer Holmberg 
Sent: den 6 november 2009 08:01
To: Jeroen van Bemmel; Brett Tate
Cc: Taisto Qvist XX; [email-masked]
Subject: RE: [sipcore] Changing contact/remotetarget in targetrefresh
response

Hi, 

Regards,

Christer

> allow INVITE 1xx/2xx's Contact to update the target during call set-up

> after the dialog has been created.  I'm not sure if the authors 
> actually intended such a restriction; I not aware of vendors actually 
> enforcing such a restriction.
> >

---

From: Brett Tate <[email-masked]>
Date: Fri, 6 Nov 2009 03:40:52 -0800

I don't disagree with the rule that Jeroen indicated.  BroadSoft may soon need our partners to follow such a rule.  Unfortunately there is nothing within rfc3261 which indicates they MUST, SHOULD, or even MAY behave that way.

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, November 05, 2009 6:44 PM
> To: Jeroen van Bemmel
> Cc: Brett Tate; Taisto Qvist XX; [email-masked]

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Nov 2009 13:48:42 +0100

Hi,

Unfortunately this is not the first time we are having this discussion.
I am not sure what (if any) the outcome has been in previous discussion,
but it may be worthwile taking a look in the archieves.

Regards,

Christer 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brett Tate
> Sent: 6. marraskuuta 2009 13:41
> To: Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX; [email-masked]
> Subject: Re: [sipcore] Changingcontact/remote target in 
> targetrefresh response
> 
> I don't disagree with the rule that Jeroen indicated.  
> BroadSoft may soon need our partners to follow such a rule.  
> Unfortunately there is nothing within rfc3261 which indicates 
> they MUST, SHOULD, or even MAY behave that way.
> 
> 
> > > request/response (1xx or 2xx) containing a Contact header is 
> > > received (with "valid" meaning syntactically correct and 
> in proper 
> > > dialog sequence, matching an existing transaction for 
> responses, and 
> > > no
> > > retransmission)
> > >
> > > up-to-date value for its Contact address, I see no reason 
> to ignore 
> > > such updates (and I do see how ignoring an updated 
> Contact can cause 
> > > failures, the peer may have obtained a new IP address for 
> example, 
> > > during the time interval it was ringing - e.g. some handset being 
> > > picked up from a docking station with a fixed LAN cable, 
> switching 
> > > to WiFi)
> > >
> > > Regards,
> > > Jeroen
>

---

From: Brett Tate <[email-masked]>
Date: Fri, 6 Nov 2009 05:09:26 -0800

Hi Christer,

Yes; there have been discussions.  Unfortunately non have actually led to an update to rfc3261.

As you know, there are some drafts concerning updates/rollbacks related to re-INVITE and UPDATE failure.  However I don't recall if there are any non expired drafts actually discussing the topic within this thread.

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Friday, November 06, 2009 7:49 AM
> To: Brett Tate; Paul Kyzivat; Jeroen van Bemmel; Taisto Qvist XX;
> [email-masked]
> Subject: RE: [sipcore] Changingcontact/remote target in target refresh
> response
> 
> 
> Hi,
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Nov 2009 14:14:35 +0100

Hi,

>As you know, there are some drafts concerning 
>updates/rollbacks related to re-INVITE and UPDATE failure.  
>However I don't recall if there are any non expired drafts 
>actually discussing the topic within this thread.

No, I don't think so.

The drafts are more related to what happens to confirmed changes (e.g.
in a 18x response) if a re-INVITE fails.

Regards,

Christer

> > I am not sure what (if any) the outcome has been in previous 
> > discussion, but it may be worthwile taking a look in the archieves.
> > 
> > Regards,
> > 
> > Christer
> > 
> > > Unfortunately there is nothing within rfc3261 which 
> indicates they 
> > > MUST, SHOULD, or even MAY behave that way.
> > >
> > >
> > > > > during the time interval it was ringing - e.g. some handset 
> > > > > being picked up from a docking station with a fixed LAN cable,
> > > switching
> > > > > to WiFi)
> > > > >
> > > > > Regards,
> > > > > Jeroen
> > >

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Nov 2009 11:04:17 -0500

> register the new IP address.

While what you say is true, it doesn't mean Jeroen is wrong.
In this situation, if you want to preserve the call, then the first 
thing you must do is change your contact address.

Once that is done, you can deal with the other things. Maybe you will 
lose your media for a bit, until you can legally do an o/a to fix it, 
but at least you will still have your call. And of course you can also 
then reregister.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 6 Nov 2009 21:56:44 +0100

Hi, 

>>If you get a new IP address, in most cases I doubt sending a new 
>>Contact header is the only thing you need to do. You probably need to 
>>update the SDP also, and for that we have more strict rules.
>> 

I didn't say he was :)

>Once that is done, you can deal with the other things. Maybe you will
lose your media for a bit, until you can legally do 
>an o/a to fix it, but at least you will still have your call. And of
course you can also then reregister.

Sure.

But, keep in mind that afaik a new Contact will not have impact on
posible re-transmissions, based on the old contact, that the UA may have
ongoing, so things can go wrong there also. And you will most likely
have issues with NAT traversal.

But, you may of course have the same issues if you send an UPDATE with
the new Contact.

Regards,

Christer 

>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/
>> 0
>>> 20127.html
>>>
>> allow INVITE 1xx/2xx's Contact to update the target during call 
>> set-up after the dialog has been created.  I'm not sure if the 
>> authors actually intended such a restriction; I not aware of vendors 
>> actually enforcing such a restriction.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 08 Nov 2009 12:55:28 +0900

Hi,

this is the approach we have followed when writing the following section 
of the re-INVITE handling draft:

http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite-01#section-12

Cheers,

Gonzalo

Paul Kyzivat wrote:
>>> INVITE 1xx/2xx's Contact to update the target during call set-up

---

From: Gonzalo Camarillo <[email-masked]>
Date: Sun, 08 Nov 2009 12:58:52 +0900

Hi,

note that the following draft deals with target refreshes as well, not 
only with SDP stuff:

http://tools.ietf.org/html/draft-camarillo-sipcore-reinvite

Cheers,

Gonzalo

---

From: Brett Tate <[email-masked]>
Date: Sun, 8 Nov 2009 10:53:39 -0800

Hi Gonzalo,

For meeting the SIPCORE "Invite Transaction Handling Correction" milestone, I propose that draft-camarillo-sipcore-reinvite be updated to also address the topic within this thread.  More specifically, I propose that the draft clearly also discuss INVITE instead of only re-INVITE (and other target-refresh requests) when discussing impacts of 1xx/2xx responses containing an updated Contact (and Record-Route).

Since the milestone currently indicates "Done", is "Invite Transaction Handling Correction" intended for something like draft-camarillo-sipcore-reinvite?  Or was the milestone for something like draft-sparks-sipcore-invfix?

Thanks,
Brett

> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Saturday, November 07, 2009 10:59 PM
> To: Christer Holmberg
> Cc: Brett Tate; [email-masked]
> Subject: Re: [sipcore] Changingcontact/remote target in target refresh
> response
> 
> Hi,
>

---

From: Brett Tate <[email-masked]>
Date: Sun, 8 Nov 2009 11:13:39 -0800

Hi Gonzalo,

In case it matters, draft-camarillo-sipcore-reinvite-01 section 12 only partially follows the indicated approach.  Section 12 currently requires the 1xx response to be reliable for the Contact to be updated.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Gonzalo Camarillo
> Sent: Saturday, November 07, 2009 10:55 PM
> To: Paul Kyzivat
> Cc: Taisto Qvist XX; [email-masked]; Jeroen van Bemmel
> received

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Nov 2009 10:55:56 +0900

Hi,

yes, that was the agreement we reached: only reliable provisional 
responses would refresh the target. The reason why unreliable 
provisional responses cannot refresh the target is that the UAC could 
receive them in a different order. The UAS does not know when or even if 
the UAC has received it.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Nov 2009 10:57:09 +0900

Hi,

yes, as Adam pointed our in the meeting, the re-INVITE draft is also 
intended to meet that milestone. I will make sure the next version of 
the draft covers explicitly initial INVITEs as well.

Thanks,

Gonzalo

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 11 Nov 2009 10:13:18 +0100

Hi Gonzalo,

The draft does talk about target refreshes, but I am not sure whether it
deals with the issue raised in this thread.

Section 12 (UAC) says:

"If the UAC receives a reliable provisional response or a 2xx response
to the target-refresh request, the UAC MUST replace the dialog's
remote target URI with the URI from the Contact header field in that
response, if present."

...and section 13 (UAS) says:

"If the UAS receives a target-refresh request that has been properly
authenticated, the UAS SHOULD generate a reliable provisional
response or a 2xx response to the target-refresh request."

But, I don't think that draft indicates whether it is allowed to update
the target from one response to another, as part of the samee
transaction.

Eg.  18x Contact:x1
     18x Contact:x2
     200 Contact:x3

I did look at section 14, but I don't think it's directly covered there
either.

So, once the issue is solved I think we should make sure it is covered
in the draft (unless it's there and I've missed it).

SECOND, if the draft is supposed to also cover initial INVITEs, we need
to remember that an unreliable provisional response can contain the
target, and it does create an early dialog.

Regards,

Christer

-----Original Message-----
From: Gonzalo Camarillo 
Sent: 8. marraskuuta 2009 6:59
To: Christer Holmberg
Cc: Brett Tate; [email-masked]
Subject: Re: [sipcore] Changingcontact/remote target in target refresh
response

Hi,

Cheers,

Gonzalo

Christer Holmberg wrote:
>> As you know, there are some drafts concerning updates/rollbacks 
>> related to re-INVITE and UPDATE failure.
>> However I don't recall if there are any non expired drafts actually 
>> discussing the topic within this thread.
> 
> No, I don't think so.
>

---

From: "Taisto Qvist XX" <[email-masked]>
Date: Wed, 11 Nov 2009 11:07:29 +0100

Hi,

Superb! This is even more than I hoped for! 

I've been going over the responses everyone been writing(being of a
somewhat impatient nature) 
trying to dig out out the answer to my intial question, (which was a lot
more simple than the 
larger picture we've been painting here, but I cant find it), so I hope
its OK that I'll restate it.

In a simple 3261 scenario, *without* update/prack etc, is it legal for a
UAS to send a 2xx with 
a different Contact than in the initial 1xx?

Since it should be ignored by the UAC, should it not be illegal? Its(the
new contact) useless anyway, 
but thats not the same.

Sorry for the persistence, and if this still needs to be discussed more
I'll accept that, but since 
I'm trying hard to show a clear picture to the firewall designer I'm
having problems with, 
I have to try :-)

Thanks for all your input.
Regards
Taisto Qvist

-----Original Message-----
From: Gonzalo Camarillo 
Sent: den 11 november 2009 02:57
To: Brett Tate
Cc: [email-masked]
Subject: Re: [sipcore] Changingcontact/remote target in targetrefresh
response

Hi,

Thanks,

Gonzalo

Brett Tate wrote:
> Hi Gonzalo,
> 
> For meeting the SIPCORE "Invite Transaction Handling Correction"
milestone, I propose that draft-camarillo-sipcore-reinvite be updated to
also address the topic within this thread.  More specifically, I propose
that the draft clearly also discuss INVITE instead of only re-INVITE
(and other target-refresh requests) when discussing impacts of 1xx/2xx
responses containing an updated Contact (and Record-Route).
> 
> Since the milestone currently indicates "Done", is "Invite Transaction
Handling Correction" intended for something like
draft-camarillo-sipcore-reinvite?  Or was the milestone for something
like draft-sparks-sipcore-invfix?

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Nov 2009 21:02:13 +0900

Hi Christer,

inline:

> the target from one response to another, as part of the samee

the rules above allow it. We can state that this is allowed explicitly, 
but nowhere in the rules this is forbidden.

> I did look at section 14, but I don't think it's directly covered there

That section will need to forbid refreshes in certain situations to 
avoid race conditions.

> target, and it does create an early dialog.

Yes, we will need to cover that.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Nov 2009 21:06:19 +0900

Hi,

> a different Contact than in the initial 1xx?

you still have not found the answer to this question because we have 
agreed to discuss it and to include the conclusion in the draft.

Cheers,

Gonzalo

---

From: Brett Tate <[email-masked]>
Date: Wed, 11 Nov 2009 05:12:25 -0800

Thanks for the response.

I agree with the reasoning; however the receiver of the INVITE does not always have the option to use (or wait to use) the reliable/best option.

For example during call setup, the caller does not indicate support for UPDATE or 100rel.  The restriction and lack of alternatives means the called party cannot refresh the target until sending INVITE 2xx.  

Is it really better to prevent the called party from refreshing the target instead of allowing a non reliable INVITE 1xx's Contact to update the target?

> Sent: Tuesday, November 10, 2009 8:56 PM
> To: Brett Tate
> Cc: [email-masked]
> > In case it matters, draft-camarillo-sipcore-reinvite-01 section 12
> only partially follows the indicated approach.  Section 12 currently
> requires the 1xx response to be reliable for the Contact to be updated.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 09:16:08 -0500

I agree with Brett here.

We are generally talking about an emergency situation, and on the 
balance I think allowing works better than not allowing.

Also, Consider the following:

   A ---> B  INVITE
   A <--- B  1xx, contact b1
   A <--- B  UPDATE, contact b2
   A ---> B  200 (UPDATE)
   A <--- B  1xx, contact (b1 or b2?)
   A <--- B  200 (INVITE), contact (b1 or b2?)

I think the questionable ones should be b2.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Nov 2009 23:19:18 +0900

Hi,

> Is it really better to prevent the called party from refreshing the
> target instead of allowing a non reliable INVITE 1xx's Contact to
> update the target?

the UAS wants to refresh the target in order to release its old address 
and start using the new one. However, even if it returns unreliable 
provisional responses with its new address, it cannot be sure that the 
UAC got them. Therefore, it cannot release the old address because it is 
not sure whether or not the UAC refreshed the target.

In any case, the draft will explain the different use cases so that they 
are clear for implementers. If the UAC could send requests to the UAS 
(e.g., UPDATE), it may make sense to allow unreliable responses to 
refresh targets after all... I will need to think about the corner cases...

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 11 Nov 2009 23:23:47 +0900

Hi Paul,

>   A <--- B  200 (INVITE), contact (b1 or b2?)

your example works with the current rules. The first 1xx sets the target 
to b1. The UPDATE refreshes the target to b2. Since the target is b2 
now, that is what the following 1xx says, and the same for the 200 OK to 
the INVITE.

The interesting case is when the UAS does not support 100rel or UPDATE 
but the UAC supports UPDATE. If we allowed unreliable responses to 
refresh targets, the UAS could use one such response to refresh the 
target and the UAC could confirm the refresh by sending an UPDATE request.

What we need to think about is whether or not it is worthwhile adding a 
few more rules (i.e., adding complexity) to cover these types of cases.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 09:52:34 -0500

There may be an important distinction here, between the following cases:

1) where there is discretion about when the old address may be released,

2)where there is no discretion - the address will go away (or already 
has) regardless of what the UA does.

We can make up whatever rules we want about case (1).
But for case (2) either you send the new address in whatever message you 
can when you must, or your call simply fails.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Nov 2009 09:56:56 -0500

> now, that is what the following 1xx says, and the same for the 200 OK to 

OK. Sorry.

> target and the UAC could confirm the refresh by sending an UPDATE request.

Is that really an interesting case? How many UAs support *receiving* 
UPDATE but not *sending* it?

> few more rules (i.e., adding complexity) to cover these types of cases.

I do think there is risk of adding complexity, but not enough to 
actually solve any added problems.

I think an interesting use case is the one where a UA suddenly can no 
longer use its old address, but would like to salvage the call. What all 
is required to make that possible? What we are discussing would, I 
think, be necessary but insufficient to solve that problem.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 12 Nov 2009 08:25:52 +0900

Hi Paul,

> UPDATE but not *sending* it?

that is what I meant when I said we need to analyze whether or not we 
should add more complexity to address weird corner cases. If the UAs 
support UPDATE, they can refresh the target using UPDATE requests. We do 
not have any problem in that case.

> think, be necessary but insufficient to solve that problem.

yes, this is the analysis we have to make. We should try and keep things 
as simple as possible. If adding complexity servers a purpose, we can 
consider doing that. However, we should avoid adding complexity that 
would not bring any benefit.

Thanks,

Gonzalo