Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
@olivermt , that is good news - I suggest closing this as bug and opening a feature request with the ability to specify multiple protos (for fallback). Is that ok ? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-91283835___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
Hello Bogdan, will test this today and give feedback. This is just a temporary fix until the udp/tcp/tls thing makes it into 2.2 right? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-90405751___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
It is not a temporary fix :). This is a real fix, as the force_send_socket() should enforce the protocol from the interface level IF the RURI does not enforce any specific protocol. So far, this was a bug :D . Step two is to extend the concept and have the ability to enforce an outgoing protocol (or many). --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-90476340___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
This force_send_socket() fix is on GIT now. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-88940030___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
@olivermt , I did some tests and come up with a simple fix for the force_send_socket() - if the RURI does not contain any proto indication, the proto will be taken from the forced socket. See the patch: https://gist.github.com/bogdan-iancu/3498b1c174b475a922d3 I did some basic tests and it did the job, but I want your blessing on it :) --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-88513813___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
The $ru is oli...@videonor.no and $du videonor.no, and the request got sent to our web provider (A-record). --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-84985579___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
All pure domains. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-85041262___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
Do you have any explicit ports in these 2 URIS ? --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-85036179___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
@olivermt , could you print in that xlog the $ru and $du, to see what are the URIs involved in the routing ? If there is a port specified in the RURI, no SRV will be performed. Without port, UDP will be assumed (for URI) and SRV will be performed to discover the port. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-81966006___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
force_send_socket() does not work for this case at all by the way. If I use force_send_socket() it actually reverts to going to the A-record, sending a tcp connection there with SIP/2.0/UDP in the Via header. Tested with: ``` xlog(DBG: Forcing tcp socket for outbound); force_send_socket(tcp:10.0.0.113:5060); ``` --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-77820552___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
@oteren, I happy you found force_send_socket() can solve your problem for the moment. I will see what is the devel effort for set_preferred_proto(list) and if it can make into 2.1 release. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-77708967___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
That function is *exactly* what I want! :) Also, it makes it possible to prefer tls always, because even if sips uri scheme takes care of tls, the RFC there *requires* every step to be tls, which might not always be possible. There should be nothing in the way of always preferring the secure route if its available. For now we can just use the force_send_socket() function for stuff that needs to exit over tcp. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-77534748___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
@etamme, I was thinking of a function to use in script - set_preferred_proto(list). If you do not want any fallback, simply put one proto in the list :) . And if a function, this can be used in a more flexible way comparing with global params. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-77450030___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
Hi, let me explain first how things do work, and then we can see how to change :) - I agree that things may be simpler (for user understanding/usage) and may be improved. So, right now the outgoing protocol is determined based on next hop URI and the set network socket. What @oteren said is correct - the transport=TCP does not have anything to do with the received proto, but it indicates the proto to be used to reach that URI (so it is not about the inbound proto, but about outbound proto). OpenSIPS looks for the transport param in target URI to see if there is any special protocol requested for the next hop URI. This is correlated withe the protocol from the requested net socket (via force_send_socket) - if they conflict, the proto URI has priority; if one in NONE, the other one will win. No proto explicitly requested - UDP will be used. So, the outbound protocol can be right now controlled via the transport URI param (this actually makes that protocol a must and gives no fallback posibility) or via the used netowork interface ( you can do force_send_socket(tcp:.) - if the URI does not forces another proto, the socket proto will be used). I would say this force_send_socket() is closest to what you need (setting a preferred transport proto without messing with the sip message), but has no fallback to another proto. Maybe adding a new function like set_preferred_proto(tcp, tls) - this will set the outbound protocol if none is forced by the target URI (via the transport param). It will allow you to change the default (which now is hardcoded to UDP) and to have a fallback. If TCP is not available, TLS will be used (like in your case when the DNS based proto selection did not return anything usable). Looking forward for input and comments :) Regards, Bogdan --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-77351332___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
If there is a preference for UDP, and an SRV lookup is done with no result, I would still want to fall through and attempt a TCP SRV lookup. It seems like this SHOULD be the way things work. If there is a parameter to place preference on one protocol vs. the other I would still want the fall through behaviour should the preferred protocol not get any SRV result. If this fall through behaviour would be undesirable for speed purposes to some, then perhaps two parameters: proto_preference, [UDP|TCP|TLS] proto_fallthrough, [1|0] In this case all the existing mechanisms to previously determine the protocol would still be in place, and these parameters would only take effect in the case where an SRV lookup with an assumed protocol happens. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-77374361___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
I looked into resolve.c sip_resolvehost() https://github.com/OpenSIPS/opensips/blob/master/resolve.c#L1742 Throughout the function the code is consistent about using tls or udp depending on the uri scheme. If there is no naptr record, then the code makes this assumption again, and calls do_srv_lookup() to get the host entity. The way the code works, it determines the protocol before doing the SRV lookup entirely - which is exactly why you are getting 476 - b/c its trying to lookup the UDP SRV, which ... doesn’t exist. I agree that this is frustration, but im not exactly certain how it could be fixed. One idea would be to have some modparam cascade_srv that would attempt to determine the proto, as the code does now, but on failure of a udp srv lookup, attempt a tcp srv lookup, and potentially lastly a tls srv lookup. The tls is a little less ... belonging in this type of feature since it has a mechanism of proto detection with a sips uri. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-77025271___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
A follow up on this issue: If you set up the tcp and sips srv records but **not** the udp one, opensips will reply `SIP/2.0 476 Unresolvable destination (476/TM).` and give up. It does not cascade down to tcp and sips at all. Tested with a simple INVITE and t_relay(). For what its worth: using t_relay(tcp:somedomain:5060) works as intended and uses tcp without the transport header. --- Reply to this email directly or view it on GitHub: https://github.com/OpenSIPS/opensips/issues/420#issuecomment-76726438___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [opensips] Allow TCP without transport=tcp header (#420)
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
