Hi all, What happens if the 1xx does not contain a contact header? According to RFC 3261, this is optional for 1xx response (see table 2, page 162), it is only mandatory for 2xx response. Does 3262 update this at all? I can't find anywhere in it that does.
Cheers Steve -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vikram Chhibber Sent: 29 March 2007 06:58 To: Singh, Indresh (SNL US) Cc: Jerry Yin; [email protected]; [EMAIL PROTECTED] Subject: Re: [Sip-implementors] SIP Contact header I guess we should not mix CANCEL handling with PRACK/UPDATE. CANCEL is send to all the forked brnaches of INVITE. PRACK/UPDATE is sent only on one particular forked INVITE branch. Therefore PRACK/UPDATE have to be send using Request-Uri constructed from 18x Contact and with Route set constructed from the Record-Route set read in reverse order of 18x. This is what IMS call-flow says. ~Vikram On 3/29/07, Singh, Indresh (SNL US) <[EMAIL PROTECTED]> wrote: > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
