Subject: [Sipping] Target Refresh Request, reINVITE

From: "Nina Garaca" <[email-masked]>
Date: Tue, 11 Jul 2006 12:21:37 +0200

Hi,

I was thinking a little more about a reINVITE as a target refresh request.

Assume the following:

The UAC sends a re-INVITE with a new local target (i.e. a new Contact header value) with a new SDP offer. 
Suppose that the UAC has sent that offer within the target refresh request (so within the existing dialog), because of the offer nature, i.e., because the offer's "demanded" using an other device, and as a consequence, a new Contact header field value in the reINVITE request.

My question is what is happening if the UAS reject a reINVITE because of the offer, it couldn't accept. Should the remote URI update be cancelled or not?

RFC3261 12.2.2 12.2.2

"Requests sent within a dialog, as any other request are atomic. If a particular request is accepted by a UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed."
"When a UAS receives a target refresh request, it MUST replace
the dialog's remote target URI with the URI from the Contact header field in that request, if present."

Regards, Nina  Garaca.

Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.6.5 - Release Date: 12/26/2004
_______________________________________________
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: Manjunath Warad <[email-masked]>
Date: Tue, 11 Jul 2006 19:35:07 +0800

Hi,

            Remote URI update must be cancelled. Because the contact
mentioned in the re-Invite will not be activated since the offer is
rejected. 

Rgds,

Manju

-----Original Message-----
From: Nina Garaca [mailto:[email-masked]] 
Sent: Tuesday, July 11, 2006 6:22 PM
To: [email-masked]
Subject: [Sipping] Target Refresh Request, reINVITE

Hi,

I was thinking a little more about a reINVITE as a target refresh
request.

Assume the following:

The UAC sends a re-INVITE with a new local target (i.e. a new Contact
header value) with a new SDP offer. 

Suppose that the UAC has sent that offer within the target refresh
request (so within the existing dialog), because of the offer nature,
i.e., because the offer's "demanded" using an other device, and as a
consequence, a new Contact header field value in the reINVITE request.

My question is what is happening if the UAS reject a reINVITE because of
the offer, it couldn't accept. Should the remote URI update be cancelled
or not?

RFC3261 12.2.2 12.2.2

"Requests sent within a dialog, as any other request are atomic. If a
particular request is accepted by a UAS, all the state changes
associated with it are performed. If the request is rejected, none of
the state changes are performed."

"When a UAS receives a target refresh request, it MUST replace
the dialog's remote target URI with the URI from the Contact header
field in that request, if present."

Regards, Nina  Garaca.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Jul 2006 17:22:29 -0400

This came up in the sipping meeting today. This seems to be ambiguous at 
the moment and needs to be clarified.

	Paul

Nina Garaca wrote:
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Jul 2006 11:07:53 -0400

I forgot to state what I think should happen when this is clarified.
IMO the new contact addresses from the reinvite should be abandoned and 
the old ones remain active for the dialog.

BUT, that leaves questions about what address the ACK for the failed 
reinvite should be sent, and what address should be used for any PRACKs 
or INFO requests sent before the reinvite fails. Also, what address 
should be used for any in-dialog requests for other dialog usages or 
non-usages.

I think the prudent thing to do would be to state that the change of 
contact address only takes place at the UAC upon receipt of a 2xx 
response, and at the UAS upon receipt of an ACK to that 2xx. (The ACK 
being delivered to the new address.)

	Paul

Paul Kyzivat wrote:
>> header value) with a new SDP offer. Suppose that the UAC has sent that 
>> offer within the target refresh request (so within the existing 
>> dialog), because of the offer nature, i.e., because the offer's 
>> "demanded" using an other device, and as a consequence, a new Contact 
>> header field value in the reINVITE request.
>>
>> My question is what is happening if the UAS reject a reINVITE because 
>> of the offer, it couldn't accept. Should the remote URI update be 
>> cancelled or not?
>>
>> RFC3261 12.2.2 12.2.2
>>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 12 Jul 2006 20:30:14 +0200

Paul,

> reinvite should be sent, and what address should be used for any PRACKs or 
> INFO requests sent before the reinvite fails. Also, what address should be 
> used for any in-dialog requests for other dialog usages or non-usages.
>

For the first part there is no question. The ACK for non-2xx MUST be sent to 
the same URI as the reINVITE, if not the INVITE state machines at proxies 
won't terminate. PRACK should use the Contact from the reliable 1xx response 
(or same URI as reINVITE if none is provided). Other dialog usages should 
keep using the current Contact until it is updated eg by 1xx/2xx responses 
to the reINVITE.

> being delivered to the new address.)

The ACK might optionally include a Contact address too, it could be 
different from the one in the INVITE. I think the UAS should update its 
remote Contact when it sends a 2xx class response (for example, if it sends 
an authentication challenge the contact should not be updated; it could be a 
hijack attempt).
The ACK cannot be challenged, so the UAS should only accept any Contact if 
the ACK contains proper Authorization

I agree that the UAC should only update for 2xx (or 1xx responses, although 
perhaps less common for reINVITE). There are security issues though, 
especially for 1xx

Regards,

jeroen

>>> offer within the target refresh request (so within the existing dialog), 
>>> because of the offer nature, i.e., because the offer's "demanded" using 
>>> an other device, and as a consequence, a new Contact header field value 
>>> in the reINVITE request.
>>>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 12 Jul 2006 20:30:14 +0200

Paul,

Regards,

jeroen

---

From: "Bob Penfield" <[email-masked]>
Date: Wed, 12 Jul 2006 19:05:08 -0400

----- Original Message ----- 
From: "Jeroen van Bemmel" <[email-masked]>
To: "Paul Kyzivat" <[email-masked]>
Cc: "Nina Garaca" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 12, 2006 2:30 PM
Subject: Re: [Sipping] Target Refresh Request, reINVITE

> For the first part there is no question. The ACK for non-2xx MUST be sent 
> to the same URI as the reINVITE, if not the INVITE state machines at 
> proxies won't terminate. PRACK should use the Contact from the reliable 
> 1xx response (or same URI as reINVITE if none is provided). Other dialog 
> usages should keep using the current Contact until it is updated eg by 
> 1xx/2xx responses to the reINVITE.
>
> remote Contact when it sends a 2xx class response (for example, if it 
> sends an authentication challenge the contact should not be updated; it 
> could be a hijack attempt).

I don't think that is a good idea. ACK is not a target refresh request. Why 
would you want to change the Contact at that point? If the UAC wanted to 
change the contact, it should have done so in the INVITE. or it would send 
another INVITE or UPDATE.

>
> I agree that the UAC should only update for 2xx (or 1xx responses, 
> although perhaps less common for reINVITE). There are security issues 
> though, especially for 1xx
>
> Regards,
>
> jeroen
>
>
>> Paul
>>
>> Paul Kyzivat wrote:

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Jul 2006 17:58:24 -0400

Jeroen van Bemmel wrote:
>> IMO the new contact addresses from the reinvite should be abandoned 
>> and the old ones remain active for the dialog.
>>
>> reinvite should be sent, and what address should be used for any 
>> PRACKs or INFO requests sent before the reinvite fails. Also, what 
>> address should be used for any in-dialog requests for other dialog 
>> usages or non-usages.
>>
> 
> For the first part there is no question. The ACK for non-2xx MUST be 
> sent to the same URI as the reINVITE, if not the INVITE state machines 
> at proxies won't terminate.

Right. I screwed up not noting that.

> PRACK should use the Contact from the 
> reliable 1xx response (or same URI as reINVITE if none is provided). 
> Other dialog usages should keep using the current Contact until it is 
> updated eg by 1xx/2xx responses to the reINVITE.

Well, right now 3262 says:

    Note that the PRACK is like any other non-INVITE request within a
    dialog.

I think that means a PRACK and other dialog usages should be sent to the 
same target. If we decide the remote target is only updated at 
successful completion of the transaction, then it would mean the PRACK 
wouldn't use the Contact from the 1xx.

Of course it is possible that the correct solution is to change this. 
But it would IMO complicate things to do so. I think it would best to 
remain consistent.

> The ACK cannot be challenged, so the UAS should only accept any Contact 
> if the ACK contains proper Authorization
> 

Hmm. I agree with Mike that it is questionable to be changing the 
contact between the invite and the ack, and given the unchallengable 
nature of ACK, its dicy to trust much from it. But what to do if there 
is a Contact in the ACK that differs from that in the INVITE is ugly.

	Paul

> Regards,
> 
> jeroen
> 
> 
>> Paul
>>
>> Paul Kyzivat wrote:
>>> This came up in the sipping meeting today. This seems to be ambiguous 
>>> at the moment and needs to be clarified.
>>>
>>>     Paul
>>>
>>> Nina Garaca wrote:
>>>> Hi,
>>>>
>>>> The UAC sends a re-INVITE with a new local target (i.e. a new 
>>>> Contact header value) with a new SDP offer. Suppose that the UAC has 
>>>> sent that offer within the target refresh request (so within the 
>>>> existing dialog), because of the offer nature, i.e., because the 
>>>> offer's "demanded" using an other device, and as a consequence, a 
>>>> new Contact header field value in the reINVITE request.
>>>>
>>>> My question is what is happening if the UAS reject a reINVITE 
>>>> because of the offer, it couldn't accept. Should the remote URI 
>>>> update be cancelled or not?
>>>>
>>>> RFC3261 12.2.2 12.2.2
>>>>
>>>> "Requests sent within a dialog, as any other request are atomic. If 
>>>> a particular request is accepted by a UAS, all the state changes 
>>>> associated with it are performed. If the request is rejected, none 
>>>> of the state changes are performed."

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 13 Jul 2006 08:45:37 +0200

Paul,

>> PRACK should use the Contact from the reliable 1xx response (or same URI 
>> as reINVITE if none is provided). Other dialog usages should keep using 
>> the current Contact until it is updated eg by 1xx/2xx responses to the 
>> reINVITE.
>
> same target. If we decide the remote target is only updated at successful 
> completion of the transaction, then it would mean the PRACK wouldn't use 
> the Contact from the 1xx.
>

For an initial INVITE, the PRACK *is* sent to the Contact from the reliable 
1xx response (using the route set from that response too). At least that has 
always been my interpretation, RFC3262 doesn't say much about it. But since 
the reliable 1xx response establishes a dialog, RFC3261 section 12.1.1 says 
the UAS MUST copy all R-R headers and MUST add a Contact. According to 
12.1.2 the UAC MUST set the remote target to the URI from that Contact (in 
the 1xx).

> Of course it is possible that the correct solution is to change this. But 
> it would IMO complicate things to do so. I think it would best to remain 
> consistent.

Following the above reasoning, "consistent" would imply that for PRACK 
following reINVITE the Contact from the 1xx is used (but the route set is 
not updated). This requires no changes, but perhaps some clarification

Regards,

Jeroen

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 13 Jul 2006 13:57:56 -0400

> the old ones remain active for the dialog.

I don't have a strong opinon on this but I guess the argument in
favor of having the change in Contact take effect in this case is that
the remote target URI is not really supposed to be up for negotiation.
It's difficult to see any advantage in allowing the UAS to reject a
change in Contact.

Anders

>>> header value) with a new SDP offer. Suppose that the UAC has sent 
>>> that offer within the target refresh request (so within the existing

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 14 Jul 2006 16:19:05 +0200

At 19:57 13/07/2006, Anders Kristensen wrote:

>>IMO the new contact addresses from the reinvite should be abandoned and the old ones remain active for the dialog.

I'm actually aware of deployments which specifically utilize the capability
to update the Contact URI. I am not able to find any other reason for failure
updating a contact then software error -- which I don't think is subject to
this discussion.

-jiri

>>BUT, that leaves questions about what address the ACK for the failed reinvite should be sent, and what address should be used for any PRACKs or INFO requests sent before the reinvite fails. Also, what address should be used for any in-dialog requests for other dialog usages or non-usages.
>>I think the prudent thing to do would be to state that the change of contact address only takes place at the UAC upon receipt of a 2xx response, and at the UAS upon receipt of an ACK to that 2xx. (The ACK being delivered to the new address.)
>>    Paul
>>Paul Kyzivat wrote:
>>
>>>This came up in the sipping meeting today. This seems to be ambiguous at the moment and needs to be clarified.
>>>
>>>    Paul
>>>
>>>Nina Garaca wrote:
>>>
>>>>Hi,
>>>>
>>>>The UAC sends a re-INVITE with a new local target (i.e. a new Contact header value) with a new SDP offer. Suppose that the UAC has sent that offer within the target refresh request (so within the existing dialog), because of the offer nature, i.e., because the offer's "demanded" using an other device, and as a consequence, a new Contact header field value in the reINVITE request.
>>>>

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 Jul 2006 13:17:54 -0400

Jiri,

Can you give more detail about the scenario you refer to?
I'd like to understand what is being done.

	Thanks,
	Paul

---

From: Jiri Kuthan <[email-masked]>
Date: Fri, 14 Jul 2006 22:19:49 +0200

>updating a contact then software error -- which I don't think is subject to

+ few more clarifications to what I meant: we were using it only for updates during
an established dialog and we were not relying on the changed contacts until the
transaction succesfully completed. In that specific application, failure of
contact-updating re-INVITE was considered application failure and led to 
discontinuation of the dialog.

-jiri