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
