Hi Nils,
I went through the RFC and I see no explicit rule which says that
the Route header
overwrites the SIPs in the URI scheme. Further before sending the message,
the UA checks
the URI scheme(SIP or SIPs) of the Request URI and not on the content of
the Require URI
to decide the transport to be used.
The RFC clearly states that if the Request URI contains a SIPs URI scheme,
the message
must be routed through TLS. So the message ends up being sent on TLS on the
port and
address mentioned in the Route header.
Regards
-Biju
Nils Ohlmeier
<[EMAIL PROTECTED]
rg> To
[EMAIL PROTECTED]
07/14/04 04:08 PM cc
[EMAIL PROTECTED]
Subject
Re: [Sip-implementors] [Sip] SIPs
Question
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."
"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
