[OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)

Oliver Severin Mulelid-Tynes notifications at github.com
Mon Mar 2 10:55:16 CET 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/devel/attachments/20150302/e3256ab2/attachment.htm>


More information about the Devel mailing list