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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 12 Jul 2006 16:35:27 -0400

Changing the Contact between INVITE and ACK sounds like a bad idea.  
Any valid reason to do this? 

Mike

> -----Original Message-----
> From: Jeroen van Bemmel [mailto:[email-masked]] 
> Sent: Wednesday, July 12, 2006 2:30 PM
> To: Paul Kyzivat (pkyzivat)
> Cc: Nina Garaca; [email-masked]
> Subject: Re: [Sipping] Target Refresh Request, reINVITE
> 
> 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. 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.
> 
> > 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
> 
> 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: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 12 Jul 2006 22:47:23 +0200

Agree, to be honest I don't see why Contact should be in ACK at all. Anybody 
can explain why table 2 in 20.1 lists Contact as 'o' for ACK?
If it is allowed, the text should probably say "if included, MUST be equal 
to the Contact used in INVITE"

Jeroen

----- Original Message ----- 
From: "Michael Hammer (mhammer)" <[email-masked]>
To: "Jeroen van Bemmel" <[email-masked]>; "Paul Kyzivat (pkyzivat)" 
<[email-masked]>
Cc: "Nina Garaca" <[email-masked]>; <[email-masked]>
Sent: Wednesday, July 12, 2006 10:35 PM
Subject: RE: [Sipping] Target Refresh Request, reINVITE

Mike