Hi.
I am pondering if Opensips might be enforcing some stuff that makes RFC
compliancy a bit inconsistent.
The problem is that the major video platform Cisco VCS does not by default
consider an URI with and without transport=tcp the same. At first I figured
that had to be RFC breaking, but the RFC actually states in RFC3261 19.1.4:
```
A URI omitting any component with a default value will not
match a URI explicitly containing that component with its
default value. For instance, a URI omitting the optional port
component will not match a URI explicitly declaring port 5060.
The same is true for the transport-parameter, ttl-parameter,
user-parameter, and method components.
```
As far as I can see, there is nothing in any of the RFCs that it is
*disallowed* to send a tcp request *without* the transport=tcp header.
Meaning that the Cisco VCS that uses TCP first and foremost will send an INVITE
on tcp without the transport header, but anything going via an
Opensips-instance will have transport=tcp added onto it.
This makes the two systems very hard to keep in step.
I figured that instead of having a philosophical debate on whether or not this
and that is RFC compliant, if we could for opensips 2.1 have either a config
that makes tcp (without the transport header) the first class citizen or a
method similar to kamalios to_tcp() (which is implementation wise *not* what we
want, since what it does is just to tack on transport=tcp) that makes opensips
use the tcp srv record instead of the udp one.
We would still like to keep a sort of cascading behavior so that for example we
can prefer that (with no NAPTR records) it first tries TLS, then TCP and then
UDP srv records.
I know that if you have the right priorizations in the NAPTR records, opensips
will go tcp before udp, but as an operator with a diverse client base we have
no way of ensuring that our clients have NAPTR capable dns providers (not even
Amazon Route53 currently supports NAPTR). Not to mention that NAPTR use is
almost non-existent 'out in the wild' of external platforms our users will call
that we have no control over at all.
In general, this change of behavior would also encompass the changes in RFC5630
that has deprecated the use of transport=tls header (since tls should be
transport-independant between sctp and tcp) if a to_tls() method was exposed.
---
Reply to this email directly or view it on GitHub:
https://github.com/OpenSIPS/opensips/issues/420_______________________________________________
Devel mailing list
Devel@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
