I think the section 12.1.2 of RFC-3261 is appropriate for our discussion and as per that 18x response with a tag will establish a dialog and thus should update the remote-target-uri.
The previous reference for 200 OK being the only response to update the remote-target-uri was applicable for dialogs which are already established. It seems our friend Bob, Penfield has already clarified this :) Regards, Indresh K Singh 12.1.2 UAC Behavior When a UAC sends a request that can establish a dialog (such as an INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., the same SIP URI can be used in messages outside this dialog) in the Contact header field of the request. If the request has a Request- URI or a topmost Route header field value with a SIPS URI, the Contact header field MUST contain a SIPS URI. Rosenberg, et. al. Standards Track [Page 71] RFC 3261 SIP: Session Initiation Protocol June 2002 When a UAC receives a response that establishes a dialog, it constructs the state of the dialog. This state MUST be maintained for the duration of the dialog. If the request was sent over TLS, and the Request-URI contained a SIPS URI, the "secure" flag is set to TRUE. The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response. -----Original Message----- From: Singh, Indresh (SNL US) Sent: Wednesday, March 28, 2007 7:19 PM To: 'Jerry Yin'; [EMAIL PROTECTED]; [email protected] Subject: RE: [Sip-implementors] SIP Contact header Good discussion. But I would differ from the intepretation of below section of RFC-3262 w.r.t to remoteTargetURI updation on the UAC side. RFC-3262 does not specifically suggest anywhere that after reception of 18x responses which would create early dialog should be saved in the dialog request URI. In absence of any such text in RFC-3262 we have to fall back to the recommendation of RFC-3261 ( RFC-3261 mentions that it's recommendation can be over-written in specific RFCs, but here there is no such over-writing of recommendation of base RFC ) Also from the perspective of treating PRACK as a non-INVITE requests within dialog. On the UAS side receiving the PRACK with different contact, this would also not cause any change in remote-target-uri. Remote Target URI can only be refreshed by a re-INVITE only. Also if we think about the UPDATE withour PRACK and UPDATE with PRACK being sent differently. The UAC then would have to check the i/c 18X response to see if PRACK is supported by UAS and then use the contact header to refresh target URI. I have not seen any such recommendation. So I still think the contact header in 18X response should be not used to build the remote-target-uri ( with/without PRACK ) unless ofcourse some section of RFC-3261/3262 does suggest so. I think this is done to be able to send CANCEL request to the same destination as original URI. If the remote-target-uri is updated with 18x contact, then CANCEL R-URI can not be built using dialog remote-target-uri information. That is what my understanding suggest :) But I also have to confess that if we think from media-exchange perspective INVITE-200OK-ACK where ACK can go to different contact as specified in 200 OK. INVITE-18X-PRACK. Prack is playing the same role for 18X as an ACK for 200OK, so why it should not be accorded same benefit as 200 OK w.r.t to updation of remote-target-uri. I do not know. It may be because of the CANCEL R-URI as I pointed above .... Do let me know if we have additional information which would suggest that 18x contact should be used to update the remote-target-uri of a dialog in some other reference documents. Regards, Indresh K Singh -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jerry Yin Sent: Wednesday, March 28, 2007 4:02 PM To: [EMAIL PROTECTED]; [email protected] Subject: Re: [Sip-implementors] SIP Contact header Please see the in-line comments. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Yong Xin > Sent: Wednesday, March 28, 2007 1:34 PM > To: [email protected] > Subject: [Sip-implementors] SIP Contact header > > > Hi, > > As per RFC 3261, the UAS MUST add a Contact header field to > the 2xx response to the INVITE. 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). > > My questions are: > > 1) Would the ACK for a non-2xx response be using this contact > address? (I assume not. My understanding is that UAC must > send ACK for a non-2xx response using the same destination > address as the INVITE) > No. The none-2xx response does not create a dialog, therefore, the ACK will be sent to the same url as Invite request. > 2) How about PRACK or UPDATE request which is sent from UAC > to UAS before the dialog is established (i.e.: 200 ok to > INVITE is not sent by UAS yet)? (I assume same as the ACK > for non-200 response). > When you send PRACK, it means you have received a reliable 1xx response, which will create an early dialog. As someone said, early dialog is a dialog. Therefore, the PRACK will be sent to the "contact" address in 1xx response. Since you shouldn't send "UPDATE" before the PRACK, therefore the UPDATE is also sent to the contact address in the early dialog. That's my understanding. As to the UPDATE without PRACK, I assume it should be sent to the same address as request url, since there's no (early) dialog is created. > Your comments are appreciated. > > Thanks, > Yong > > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
