Hi Biju,
As per my understanding, you are facing a problem in below situation.
1. Your UAS is listening on TLS port.
2. Your immediate Proxy is using the TCP port.
So, Your request message contains,
The Request URI with the UAS address i.e. SIPS
and the top most route header is of Proxy i.e. SIP
As per RFC 3261:
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."
As per the RFC, you are supposed to use only TLS.
But as your next hop Proxy which doesn't support the
TLS transport, you cannot forward the request over
TLS as per RFC.
Upto now there is no solution identified in the mailing lists
about this problem.
Until this problem gets solved in some machanism,
I suggest you to use the transport that is supported
by the next hop entity.
i.e. In this situation, you can use TCP to send the
request to your immediate Proxy, instead of trying
to send over TLS.
With this approach, the major problem is you will be violating
the MUST condition from the RFC.
I request others to provide their valuable opinions on this issue.
Regards
Rao
K Biju/BLR/HSS
07/16/04 07:54 PM To
sip at ietf.org
cc
Subject
Bug in RFC for handling SIPS ??? Fw
[Sip] SIPs Question
Hi,
Can the following scenario be considered a problem in handling SIPS
URI scheme ?? Any suggestions or enhancements in this regard is
welcomed.
Thanks in Advance
-Biju
----- Forwarded by K Biju/BLR/HSS on 07/16/04 07:55 PM -----
K Biju/BLR/HSS
07/12/04 09:42 AM To
sip at ietf.org,
cc
Subject
[Sip] SIPs Question
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:bob at biloxi.com SIP/2.0
Contact: <sips:alice at alice-pc.com>
...
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:bob at bobs-pc.biloxi.com SIP/2.0
Record-Route: <sip:ProxyIP:5060;transport=tcp;lr>
Contact: <sips:alice at alice-pc.com>
...
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:alice at alice-pc.com SIP/2.0
Contact: <sip:bob at bobs-pc.biloxi.com>
Route: <sip:ProxyIP:5060;transport=tcp;lr>
...
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: pic48450.jpg)
K Biju
(Embedded image moved to file: pic49191.jpg)
07/07/2004 07:39 PM
(Embedded image moved to file: pic09058.jpg)
To: Jonathan Rosenberg <jdrosen at dynamicsoft.com>
cc: kbiju at hss.hns.com, sip at ietf.org
Subject: Re: [Sip] SIPs Question (Document link: K Biju)
Hi ,
See inline >>>> for my response
Thanks & Regards
-Biju K
Jonathan Rosenberg <jdrosen at dynamicsoft.com> on 07/06/2004 11:24:59 PM
To: kbiju at hss.hns.com
cc: sip at ietf.org
Subject: Re: [Sip] SIPs Question
inline.
kbiju at hss.hns.com 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
jdrosen at dynamicsoft.com 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."Attachment:
pic48450.jpg
Description: JPEG image
Attachment:
pic49191.jpg
Description: JPEG image
Attachment:
pic09058.jpg
Description: JPEG image
_______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors at cs.columbia.edu for questions on current sip Use sipping at ietf.org for new developments on the application of sip
