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." _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
