Subject: RE: [Sipping] Target Refresh Request, reINVITE

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 18 Jul 2006 23:08:55 +0200

Hi, 

>>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.)
>>
> 
>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

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.

[CHH] I agree that one should not be able to use ACK for target refresh.
Now, even if Contact is allowed ACK, is it actually said somewhere that
ACK can be used for a target refresh?

Regards,

Christer

> 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,
>>>>
>>>> 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
>>>
>>> _______________________________________________
>>> 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
>>>
>>
>> _______________________________________________
>> 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
> 

_______________________________________________
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

_______________________________________________
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: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 19 Jul 2006 16:35:09 +0200

Hi, 

>>I am talking about the Contact header, not SDP.
>ok, i rephrase my question:  what that works today with forking would
we loose if we allow contact header AND sdp only on >invite and 200 ok?

First, I am the first to agree that there are things which may not work
very well with forking. "How does this work with forking?" is one of the
first questions I ask myself when I see a new function/extension :)

However, I believe there are a number of things, that require SDP and/or
Contact in 18x, that DO work with forking. And, even if they don't, your
proposed restriction would prevent those functions from being used also
in non-forking cases.

Regards,

Christer