Hi Biju, but why do you care about the Request-URI? The next hop of the Route header is a loose router, so you should not care about the content of the Request-URI. The content of the first Route header is the target. I did not found an explicit rule which says that Route overwrites SIPS (in R-URI), but it seems to be obvious to me.
Regards Nils Ohlmeier On Tuesday 13 July 2004 13:52, [EMAIL PROTECTED] wrote: > Hi Nils, > Adding two RR headers will not solve the problem, because > the Request URI in the NOTIFY message is still SIPs and as per the RFC > Section 8.1.2 (UAC sending a request): "Independent of which URI is used as > input to the > procedures of [4], if the Request-URI specifies a SIPS resource, the UAC > MUST follow the procedures > of [4] as if the input URI were a SIPS URI", subsequent messages are to be > sent on TLS. > So the Proxy will still end up sending using TLS in the TCP Port (5060). > > Regards > -Biju > > > > > Nils Ohlmeier <[EMAIL PROTECTED]> on 07/12/2004 08:02:09 PM > > > To: [EMAIL PROTECTED] > cc: [EMAIL PROTECTED] > > Subject: Re: [Sip-implementors] [Sip] SIPs Question > > > Hello, > > I allready suggest on the SIP mailing list to use two RR headers. See in > line > for an example. > > Regards > Nils Ohlmeier > > On Monday 12 July 2004 06:12, [EMAIL PROTECTED] wrote: > > Hi, > > Let me try explaining the scenario in > > simple terms. Consider the following setup > > where P is the proxy responsible for Bob's > > domain (biloxi.com). > > > > Alice --> P --> Bob > > > > Alice starts the dialog as: > > SUBSCRIBE sips:[EMAIL PROTECTED] SIP/2.0 > > Contact: <sips:[EMAIL PROTECTED]> > > ... > > > > However, P decides to switch from TLS to TCP when > > forwarding the call to Bob (it is allowed to do > > so as SIPS only guarantees TLS to be used till > > the domain of the callee; there are also sections > > that talk about a proxy being on a security perimeter... > > so a switch from TLS to TCP is legal). Since it > > switches from TLS to TCP, it inserts a Record-Route > > and the message that reaches Bob will look like: > > > > SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 > > Record-Route: <sip:ProxyIP:5060;transport=tcp;lr> > > Contact: <sips:[EMAIL PROTECTED]> > > ... > > With two RR it would look like this: > > SUBSCRIBE sip:[EMAIL PROTECTED] SIP/2.0 > Record-Route: <sip:ProxyIP:5060;transport=tcp;lr> > Record-Route: <sips:ProxyIP:5061;transport=tls;lr> > Contact: <sips:[EMAIL PROTECTED]> > > > Ofcourse, in the response path, the proxy P > > modifies its Record-Route to become a SIPS URI > > so that the hop from Alice to P remains on TLS > > and the hop from P to Bob remains on TCP. > > > > Now, when Bob sends a NOTIFY to Alice, the message > > would be formed as : > > > > NOTIFY sips:[EMAIL PROTECTED] SIP/2.0 > > Contact: <sip:[EMAIL PROTECTED]> > > Route: <sip:ProxyIP:5060;transport=tcp;lr> > > ... > > And the NOTIFY will look like this: > > NOTIFY sips:[EMAIL PROTECTED] SIP/2.0 > Contact: <sip:[EMAIL PROTECTED]> > Route: <sip:ProxyIP:5060;transport=tcp;lr> > Route: <sips:ProxyIP:5061;transport=tls;lr> > > So Bob will use a normal TCP connection to the proxy. And Alice will still > use > a TLS connection. Now you only have to make your proxy smart enough to > handle > this conversion with a less overhead as possible (avoid a local TLS > connection to itself). > > This is may be not the best solution, but is should work. > > Greetings > Nils Ohlmeier > > > Though one would expect the NOTIFY to be sent to > > ProxyIP:5060 on TCP, the following rule of RFC 3261 > > suggests otherwise: > > Section 8.1.2 (UAC sending a request): > > "Independent of which URI is used as input to the > > procedures of [4], if the Request-URI specifies a > > SIPS resource, the UAC MUST follow the procedures > > of [4] as if the input URI were a SIPS URI." > > > > Going by the above rule, though the ordered IP:port:transport > > is ProxyIP:5060:tcp, the request is still expected > > to be sent on TLS !! So now, Bob will send the request > > to ProxyIP:5060 on TLS and proxy P will probably fail > > to parse the message as this is its TCP interface. > > > > This problem has been raised by Christer Holmberg > > about a year back. Till a bis revision of the RFC comes > > out, what are implementations expected to do in the > > above case ?? > > > > Thanks for your time. Christer, if you are aware of what > > was the (maybe offline) consensus, please comment. > > > > > > Thanks & Regards > > -Biju > > ---------------------- Forwarded by K Biju/BLR/HSS on 07/09/2004 01:43 PM > > --------------------------- > > (Embedded image moved to file: pic60951.jpg) > > K Biju > > (Embedded image moved to file: pic16579.jpg) > > 07/07/2004 07:39 PM > > (Embedded image moved to file: pic55181.jpg) > > > > > > To: Jonathan Rosenberg <[EMAIL PROTECTED]> > > cc: [EMAIL PROTECTED], [EMAIL PROTECTED] > > > > Subject: Re: [Sip] SIPs Question (Document link: K Biju) > > > > > > Hi , > > See inline >>>> for my response > > > > Thanks & Regards > > -Biju K > > > > > > > > Jonathan Rosenberg <[EMAIL PROTECTED]> on 07/06/2004 11:24:59 PM > > > > > > To: [EMAIL PROTECTED] > > cc: [EMAIL PROTECTED] > > > > Subject: Re: [Sip] SIPs Question > > > > > > inline. > > > > [EMAIL PROTECTED] wrote: > > > Hi all, > > > I have come across a typical scenario when using TLS. > > > > > > A UAC sends a request (SUBSCRIBE) over TLS and the Proxy Server (P1) > > on > > > > the > > > domain of the UAS converts this request from TLS to non-TLS and also > > > record-routes > > > this dialog. > > > The Proxy server hence inserts the SIP URI scheme in the Record-Route > > > header, > > > when sending this request to the UAS. > > > > > > Now for subsequent messages (NOTIFY) from UAS to a UAC, UAS sends it on > > > TLS. > > > > It shouldn't. The next hop, as far as its concerned, is a URI that is > > not using TLS transport, unless the DNS SRV procedures when resolving > > the record-routed URI would indicate TLS. > > > > >>>>> In my mentioned case the Request-URI sent by the UAC has a SIPS > > >>>>> URI. So as per the RFC section 8.1.2 "Independent of which URI is > > > > used > > > > >>>>> as input to the procedures of [4], if the Request-URI specifies a > > > > SIPS > > > > >>>>> resource, the UAC MUST follow the procedures of [4] as if the input > > > > URI > > > > >>>>> were a SIPS URI." > > >>>>> Hence subsequent messages (NOTIFY) are getting sent on TLS using a > > >>>>> non-TLS port, set in the Route Header. > > > > > > But since the Proxy has record-routed the request, UAS sends the > > > > responses > > > > > to the > > > address mentioned in the Route header. > > > This being a non-TLS transport, the UAS ends up sending the TLS > > response > > > on > > > > > a > > > non-TLS port. > > > This behavior is still in accordance with RFC 3261- section12.1.1. > > > > Right. This is the correct behavior. > > > > > I have seen a similar issue raised in this mailing list sometime before > > > > but > > > > > no concrete solution was > > > available. > > > http://www1.ietf.org/mail-archive/web/sip/current/msg06712.html > > > > > > How is this planned to be handled ?? > > > > I'm not sure I see the problem. If you want tls all the way, the UAC > > should have sent the request with a sips URI. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > > Chief Technology Officer Parsippany, NJ 07054-2711 > > dynamicsoft > > [EMAIL PROTECTED] FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > > > > "DISCLAIMER: This message is proprietary to Hughes Software Systems > > Limited > > > (HSS) and is intended solely for the use of the individual to whom it is > > addressed. It may contain privileged or confidential information and > > should not be circulated or used for any purpose other than for what it > > is > > > intended. If you have received this message in error, please notify the > > originator immediately. If you are not the intended recipient, you are > > notified that you are strictly prohibited from using, copying, altering, > > or > > > disclosing the contents of this message. HSS accepts no responsibility > > for > > > loss or damage arising from the use of the information transmitted by > > this > > > email including damage from virus." > > "DISCLAIMER: This message is proprietary to Hughes Software Systems Limited > (HSS) and is intended solely for the use of the individual to whom it is > addressed. It may contain privileged or confidential information and > should not be circulated or used for any purpose other than for what it is > intended. If you have received this message in error, please notify the > originator immediately. If you are not the intended recipient, you are > notified that you are strictly prohibited from using, copying, altering, or > disclosing the contents of this message. HSS accepts no responsibility for > loss or damage arising from the use of the information transmitted by this > email including damage from virus." _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
