@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:
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:
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
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
@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
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
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
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
@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
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);
@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:
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
@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
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
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
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
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:
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
18 matches
Mail list logo
