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
