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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 13 Jul 2006 07:33:40 -0400

Could you just ignore the ACK Contact?

BTW, I sense that you are trying to cover all the bases for Contact
changes:

          UAC  UAS
Change?   No   No   (existing)
Change?   Yes  No
Change?   No   Yes
Change?   Yes  Yes

Mike

> -----Original Message-----
> From: Paul Kyzivat (pkyzivat) 
> Sent: Wednesday, July 12, 2006 5:58 PM
> To: Jeroen van Bemmel
> Cc: Nina Garaca; [email-masked]
> Subject: Re: [Sipping] Target Refresh Request, reINVITE
> 
> 
> 
> Jeroen van Bemmel wrote:
> > Paul,
> > 
> > 
> >> 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.
> >>
> > 
> > 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.
> 
> >> 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.
> 
> 	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,
> >>>>
> >>>> 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: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 13:52:20 -0400

I have been convinced that ACK should not be considered a target refresh 
request. This will require a clarification somewhere.

	Paul