Hi, RFC 3261 states that using a SIP URI in the Request Line or Route header with sips scheme and ;transport=tls is deprecated, and instead sips schema and ;transport=tcp (or absence of ;transport param) should be used.
Sip-Router behaves correctly when the URI schema is sips (it performs _sips._tcp SRV query or directly tries to open a TLS connection if the URI has ;transport=tcp).
But in case Sip-Router receives a request with RURI "sip:alice@domain.org;transport=tls" (and no Route header) it ignores the transport param and behaves as if the URI would be "sip:alice@domain.org;transport=udp".
I opened a thread in sip-implementors and the conclusion is that a proxy receiving a request with sip sheme and ;transport=tls should use TLS transport (so if there is no port it should use 5061):
https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-June/027277.ht... https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-June/027299.ht...
Some responses during the thread:
------------------ Is RFC 3261 really stating that transport=tls is no longer valid? The mention of transport=tls being deprecated in "Section 26.2.2 SIPS URI Scheme" indicates that the use of the transport=tls option is deprecated for SIPS URIs which means it should still be a perfectly valid option for SIP URIs. And in fact in "Section 28.2 Minor Functional Changes" one of the items is "Added TLS and SCTP as valid SIP transports" so it would seem strange for RFC 3261 to add it and deprecate it at the same time. And of course transport=tls is perfectly valid according to the BNF. ------------------
------------------ My understanding is that transport=tls is a valid option for SIP URIs. For SIPS URIs it's a valid but deprecated option and I guess the reason it's deprecated is that TLS is already implied to be mandatory. -----------------
In fact, some UA's set a Contact "sip:user@IP:PORT;transport=tls" when they register using TLS. Incoming in-dialog requests to such UA would fail as the proxy would try to open/reuse a TCP connection with such IP:PORT (rather than a TLS connection).
IMHO if Sip-Router receives a request with transport=tls it should resolve the domain (A/AAAA query if it's a domain), set port =5061 (if port is not given) and open/reuse a TLS connection.
Regards.
Hello,
On Jul 1, 2011, at 11:23 AM, Iñaki Baz Castillo ibc@aliax.net wrote:
Hi, RFC 3261 states that using a SIP URI in the Request Line or Route header with sips scheme and ;transport=tls is deprecated, and instead sips schema and ;transport=tcp (or absence of ;transport param) should be used.
Sip-Router behaves correctly when the URI schema is sips (it performs _sips._tcp SRV query or directly tries to open a TLS connection if the URI has ;transport=tcp).
But in case Sip-Router receives a request with RURI "sip:alice@domain.org;transport=tls" (and no Route header) it ignores the transport param and behaves as if the URI would be "sip:alice@domain.org;transport=udp".
Is there any dst_uri set for such request? I have been using sip uri with transport=tls and all was fine so far.
Cheers, Daniel
I opened a thread in sip-implementors and the conclusion is that a proxy receiving a request with sip sheme and ;transport=tls should use TLS transport (so if there is no port it should use 5061):
https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-June/027277.ht... https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-June/027299.ht...
Some responses during the thread:
Is RFC 3261 really stating that transport=tls is no longer valid? The mention of transport=tls being deprecated in "Section 26.2.2 SIPS URI Scheme" indicates that the use of the transport=tls option is deprecated for SIPS URIs which means it should still be a perfectly valid option for SIP URIs. And in fact in "Section 28.2 Minor Functional Changes" one of the items is "Added TLS and SCTP as valid SIP transports" so it would seem strange for RFC 3261 to add it and deprecate it at the same time. And of course transport=tls is perfectly valid according to the BNF.
My understanding is that transport=tls is a valid option for SIP URIs. For SIPS URIs it's a valid but deprecated option and I guess the reason it's deprecated is that TLS is already implied to be mandatory.
In fact, some UA's set a Contact "sip:user@IP:PORT;transport=tls" when they register using TLS. Incoming in-dialog requests to such UA would fail as the proxy would try to open/reuse a TCP connection with such IP:PORT (rather than a TLS connection).
IMHO if Sip-Router receives a request with transport=tls it should resolve the domain (A/AAAA query if it's a domain), set port =5061 (if port is not given) and open/reuse a TLS connection.
Regards.
-- Iñaki Baz Castillo ibc@aliax.net
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2011/7/1 Daniel-Constantine Mierla miconda@gmail.com:
Is there any dst_uri set for such request? I have been using sip uri with transport=tls and all was fine so far.
Hi Daniel, there is no dst_uri, it's a very simple script just to test it.
However, forget my previous mail. I'm a bit annoyed as now it works perfectly. I've upgraded to master branch yesterday but I've seen no recent commets to TM/TLS, so I assume I did something really wrong in my previous experiments ;)
Thanks a lot.
Hello,
On Jul 1, 2011, at 2:11 PM, Iñaki Baz Castillo ibc@aliax.net wrote:
2011/7/1 Daniel-Constantine Mierla miconda@gmail.com:
Is there any dst_uri set for such request? I have been using sip uri with transport=tls and all was fine so far.
Hi Daniel, there is no dst_uri, it's a very simple script just to test it.
However, forget my previous mail. I'm a bit annoyed as now it works perfectly. I've upgraded to master branch yesterday but I've seen no recent commets to TM/TLS, so I assume I did something really wrong in my previous experiments ;)
You hit "it does not work today no matter what you try" feature of the life. It requires the magical next night to be finished :-).
Cheers, Daniel
Thanks a lot.
-- Iñaki Baz Castillo ibc@aliax.net
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2011/7/1 Daniel-Constantine Mierla miconda@gmail.com:
You hit "it does not work today no matter what you try" feature of the life. It requires the magical next night to be finished :-).
Right, tomorrow can always be a better day :)
-
Daniel-Constantine Mierla -
Iñaki Baz Castillo