All,
Eric pointed out that this is related to there being onoUDP SRV records and
only TCP TLS records.
On Fri, May 22, 2015 at 2:34 PM, Eric Tamme e...@uphreak.com wrote:
OpenSIPS follows RFC3263, see sip_resolvehost() in resolve.c for more
details. If you send a a request that is not a
Follow up to the group: the domain he is trying to reach only has SRV
records for TLS and TCP, so he has to append ;transport=tcp to his
request URI to force a TCP SRV lookup in opensips.
On 05/22/2015 01:34 PM, Eric Tamme wrote:
OpenSIPS follows RFC3263, see sip_resolvehost() in resolve.c
Hi Vlad,
Just tested the lastest sources and now the websocket connection isn't
droped anymore if I use the tcp_persistent_flag!
Many thanks!
Patrick
On Wed, May 20, 2015 at 9:40 AM, Vlad Paiu vladp...@opensips.org wrote:
Hello,
I've just fixed on GIT the issue where the tcp_persistent_flag
I've been stepping through the residential script and looking at rfc3665 in
order to get an understanding of how things work. So far so good on simple
INVITES, REGISTERS, etc. But I'm a little confused on case 3.9 Unsuccessful
Busy. It might be my lack of complete understanding of loose_route..
Hello all!
This month's public meeting is scheduled for the next Wednesday,
27.05.2015, at 13:00 UTC[1].
The topic for this session is a discussion on how to create a
distributed user location mechanism. More information on the topic will
be sent by the begining of the next week.
As
OpenSIPS does not appear to be resolving the SIP address of a domain that
is provided by WebEx.com. When I dial dlar...@blahblah.webex.com the call
gets forwarded to the IP address of the webserver but it really should be
going to the IP address from an SRV record. I believe the OpenSIPS default
It seems that the meeting is on Wednesday 27.05.2015, at 15:00 UTC
(according to the timeanddate link).
-ovidiu
On Fri, May 22, 2015 at 1:19 PM, Maxim Sobolev sobo...@sippysoft.com wrote:
Hi Razvan, my only suggestion is to move those meetings either early in the
morning or later in the
OpenSIPS follows RFC3263, see sip_resolvehost() in resolve.c for more
details. If you send a a request that is not a sips uri, to a plain
domain with no transport parameter or port, opensips will do a udp SRV
lookup on the domain.
Can you provide the actual domain please? If you cant - do a
James,
Only SIP Requests are processed by the route function. That is why it makes
sense for the INVITEs, REGISTERs, and OPTIONs, BYEs, ACKs, etc. The 486 is a
reply and is handled by OpenSIPS according to normal SIP rules. It will not
cause the script to run at all unless you are using the
