23 Nov
2005
23 Nov
'05
8:12 p.m.
All,
I'm trying to get SRV lookups to work with OpenSER 1.0.0. I've exhausted every
avenue of documentation including newsgroups, various forums etc.
Using t_relay, OpenSER seems to be performing the correct DNS SRV queries and obtaining a
list of hosts to try. Below are the relevant sections of my DNS zone file. We're
talking UDP, and based on the priority and weights below, OpenSER should be basically
doing a round-robin approach, and it seems to be.
The problem occurs when one of the hosts is not contactable. OpenSER simply stops and does
not try the next host in it's list. I would have thought that for OpenSER to fully
support SRV lookups, it should try each until it is successful. After all, that's a
large part of the whole point of SRV records.
Does the t_relay() function have logic within itself to keep trying hosts until it gets a
connection? What would be the definition a failure that would make it move onto the next
host be anyway? Network failure certainly, but would a 'Not found' be considered a
failure that would cause it to move on? Would anything other than an ACK be a failure?
Is there some variable I can set or some function I can call that causes t_relay() to
retry all hosts in it's SRV list?
Without this feature, OpenSER's usefulness is very limited.
Help very much appreciated.
Doug
bil-pdev-3 IN A 192.168.10.4
proxy1 IN CNAME bil-pdev-3
proxy2 IN CNAME bil-pdev-3
proxy.bil.voip.com. IN NAPTR 50 50 "s"
"SIPS+D2T" "" _sips._tcp.proxy.bil.voip.com.
proxy.bil.voip.com. IN NAPTR 60 60 "s"
"SIP+D2U" "" _sip._udp.proxy.bil.voip.com.
proxy.bil.voip.com. IN NAPTR 70 40 "s"
"SIP+D2T" "" _sip._tcp.proxy.bil.voip.com.
_sips._tcp.proxy.bil.voip.com. IN SRV 100 10 5061
proxy1.proxy.bil.voip.com.
_sips._tcp.proxy.bil.voip.com. IN SRV 100 10 5061
proxy2.proxy.bil.voip.com.
_sip._udp.proxy.bil.voip.com. IN SRV 100 10 5060 proxy1.proxy.bil.voip.com.
; This line and the next are SRV records being looked up
_sip._udp.proxy.bil.voip.com. IN SRV 100 10 5060 proxy2.proxy.bil.voip.com.
;
_sip._tcp.proxy.bil.voip.com. IN SRV 100 10 5060
proxy1.proxy.bil.voip.com.
_sip._tcp.proxy.bil.voip.com. IN SRV 100 10 5060
proxy2.proxy.bil.voip.com.
*._tcp IN SRV 0 0 0 .
*._udp IN SRV 0 0 0 .
;
23 Nov
23 Nov
8:57 p.m.
Douglas Garstang wrote:
All,
I'm trying to get SRV lookups to work with OpenSER 1.0.0. I've exhausted every
avenue of documentation including newsgroups, various forums etc.
Using t_relay, OpenSER seems to be performing the correct DNS SRV queries and obtaining a
list of hosts to try. Below are the relevant sections of my DNS zone file. We're
talking UDP, and based on the priority and weights below, OpenSER should be basically
doing a round-robin approach, and it seems to be.
The problem occurs when one of the hosts is not contactable. OpenSER simply stops and
does not try the next host in it's list. I would have thought that for OpenSER to
fully support SRV lookups, it should try each until it is successful. After all,
that's a large part of the whole point of SRV records.
Does the t_relay() function have logic within itself to keep trying hosts until it gets a
connection? What would be the definition a failure that would make it move onto the next
host be anyway? Network failure certainly, but would a 'Not found' be considered a
failure that would cause it to move on? Would anything other than an ACK be a failure?
It's defined in RFC3263 section 4.3 "Details of RFC 2782 Process":
For SIP requests, failure occurs if the transaction layer reports a
503 error response or a transport failure of some sort (generally,
due to fatal ICMP errors in UDP or connection failures in TCP).
Failure also occurs if the transaction layer times out without ever
having received any response, provisional or final (i.e., timer B or
timer F in RFC 3261 [1] fires). If a failure occurs, the client
SHOULD create a new request, which is identical to the previous, but
has a different value of the Via branch ID than the previous (and
therefore constitutes a new SIP transaction). That request is sent
to the next element in the list as specified by RFC 2782.
/Mikael
Is there some variable I can set or some function I
can call that causes t_relay() to retry all hosts in it's SRV list?
Without this feature, OpenSER's usefulness is very limited.
Help very much appreciated.
Doug
24 Nov
24 Nov
11:25 a.m.
Douglas Garstang wrote:
All,
I'm trying to get SRV lookups to work with OpenSER 1.0.0. I've
exhausted every avenue of documentation including newsgroups, various
forums etc.
Using t_relay, OpenSER seems to be performing the correct DNS SRV
queries and obtaining a list of hosts to try. Below are the relevant
sections of my DNS zone file. We're talking UDP, and based on the
priority and weights below, OpenSER should be basically doing a
round-robin approach, and it seems to be.
The problem occurs when one of the hosts is not contactable. OpenSER
simply stops and does not try the next host in it's list. I would
have thought that for OpenSER to fully support SRV lookups, it should
try each until it is successful. After all, that's a large part of
the whole point of SRV records.
(open)ser does not support SRV failover. It just looks for
_sip._protocol and uses the first found record. No failover if there is
a problem with the destination.
Does the t_relay() function have logic within itself
to keep trying
hosts until it gets a connection? What would be the definition a
no
failure that would make it move onto the next host be
anyway? Network
failure certainly, but would a 'Not found' be considered a failure
that would cause it to move on? Would anything other than an ACK be a
failure?
If you receive a SIP response, than there is no transport failure -> no
failover to other SRV hosts.
Is there some variable I can set or some function I
can call that
causes t_relay() to retry all hosts in it's SRV list? Without this
feature, OpenSER's usefulness is very limited.
no :-(
klaus
Help very much appreciated. Doug
bil-pdev-3 IN A 192.168.10.4
proxy1 IN CNAME bil-pdev-3
proxy2 IN CNAME bil-pdev-3
proxy.bil.voip.com. IN NAPTR 50 50 "s"
"SIPS+D2T" "" _sips._tcp.proxy.bil.voip.com. proxy.bil.voip.com.
IN NAPTR 60 60 "s" "SIP+D2U" ""
_sip._udp.proxy.bil.voip.com.
proxy.bil.voip.com. IN NAPTR 70 40 "s"
"SIP+D2T" "" _sip._tcp.proxy.bil.voip.com.
_sips._tcp.proxy.bil.voip.com. IN SRV 100 10 5061
proxy1.proxy.bil.voip.com. _sips._tcp.proxy.bil.voip.com. IN
SRV 100 10 5061 proxy2.proxy.bil.voip.com.
_sip._udp.proxy.bil.voip.com. IN SRV 100 10 5060
proxy1.proxy.bil.voip.com. ; This line and the next are SRV records
being looked up _sip._udp.proxy.bil.voip.com. IN SRV
100 10 5060 proxy2.proxy.bil.voip.com. ;
_sip._tcp.proxy.bil.voip.com. IN SRV 100 10 5060
proxy1.proxy.bil.voip.com. _sip._tcp.proxy.bil.voip.com. IN
SRV 100 10 5060 proxy2.proxy.bil.voip.com.
*._tcp IN SRV 0 0 0
. *._udp IN SRV 0 0
0 . ;
_______________________________________________ Users mailing list
Users(a)openser.org http://openser.org/cgi-bin/mailman/listinfo/users
12:02 p.m.
Klaus Darilion wrote:
Douglas Garstang wrote:
The next SRV record should be tried if a 503 "Service Unavailable" SIP
response message is received, according to RFC3263 section 4.3.
/Mikael
All,
I'm trying to get SRV lookups to work with OpenSER 1.0.0. I've
exhausted every avenue of documentation including newsgroups, various
forums etc.
Using t_relay, OpenSER seems to be performing the correct DNS SRV
queries and obtaining a list of hosts to try. Below are the relevant
sections of my DNS zone file. We're talking UDP, and based on the
priority and weights below, OpenSER should be basically doing a
round-robin approach, and it seems to be.
The problem occurs when one of the hosts is not contactable. OpenSER
simply stops and does not try the next host in it's list. I would
have thought that for OpenSER to fully support SRV lookups, it should
try each until it is successful. After all, that's a large part of
the whole point of SRV records.
(open)ser does not support SRV failover. It just looks for
_sip._protocol and uses the first found record. No failover if there is
a problem with the destination.
Does the t_relay() function have logic within
itself to keep trying
hosts until it gets a connection? What would be the definition a
no
failure that would make it move onto the next
host be anyway? Network
failure certainly, but would a 'Not found' be considered a failure
that would cause it to move on? Would anything other than an ACK be a
failure?
If you receive a SIP response, than there is no transport failure -> no
failover to other SRV hosts.
12:56 p.m.
Hi,
this problem (failover based on SRV) may find a answer with the new
serial forking support that I plan to add in core. See me post on devel:
http://openser.org/pipermail/devel/2005-November/001184.html
regards,
bogdan
Mikael Magnusson wrote:
Klaus Darilion wrote:
Douglas Garstang wrote:
The next SRV record should be tried if a 503 "Service Unavailable" SIP
response message is received, according to RFC3263 section 4.3.
/Mikael
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
All,
I'm trying to get SRV lookups to work with OpenSER 1.0.0. I've
exhausted every avenue of documentation including newsgroups, various
forums etc.
Using t_relay, OpenSER seems to be performing the correct DNS SRV
queries and obtaining a list of hosts to try. Below are the relevant
sections of my DNS zone file. We're talking UDP, and based on the
priority and weights below, OpenSER should be basically doing a
round-robin approach, and it seems to be.
The problem occurs when one of the hosts is not contactable. OpenSER
simply stops and does not try the next host in it's list. I would
have thought that for OpenSER to fully support SRV lookups, it should
try each until it is successful. After all, that's a large part of
the whole point of SRV records.
(open)ser does not support SRV failover. It just looks for
_sip._protocol and uses the first found record. No failover if there
is a problem with the destination.
Does the t_relay() function have logic within
itself to keep trying
hosts until it gets a connection? What would be the definition a
no
failure that would make it move onto the next
host be anyway? Network
failure certainly, but would a 'Not found' be considered a failure
that would cause it to move on? Would anything other than an ACK be a
failure?
If you receive a SIP response, than there is no transport failure ->
no failover to other SRV hosts.
2:02 p.m.
I think many of us just assume that if SRV queries are supported, then
the failover piece will work as well. I had the same experience with
Asterisk. It only only reads the first record.
- Daryl
On 11/24/05, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
Hi,
this problem (failover based on SRV) may find a answer with the new
serial forking support that I plan to add in core. See me post on devel:
http://openser.org/pipermail/devel/2005-November/001184.html
regards,
bogdan
Mikael Magnusson wrote:
Klaus Darilion wrote:
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Douglas Garstang wrote:
The next SRV record should be tried if a 503 "Service Unavailable" SIP
response message is received, according to RFC3263 section 4.3.
/Mikael
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
All,
I'm trying to get SRV lookups to work with OpenSER 1.0.0. I've
exhausted every avenue of documentation including newsgroups, various
forums etc.
Using t_relay, OpenSER seems to be performing the correct DNS SRV
queries and obtaining a list of hosts to try. Below are the relevant
sections of my DNS zone file. We're talking UDP, and based on the
priority and weights below, OpenSER should be basically doing a
round-robin approach, and it seems to be.
The problem occurs when one of the hosts is not contactable. OpenSER
simply stops and does not try the next host in it's list. I would
have thought that for OpenSER to fully support SRV lookups, it should
try each until it is successful. After all, that's a large part of
the whole point of SRV records.
(open)ser does not support SRV failover. It just looks for
_sip._protocol and uses the first found record. No failover if there
is a problem with the destination.
Does the t_relay() function have logic within
itself to keep trying
hosts until it gets a connection? What would be the definition a
no
failure that would make it move onto the next
host be anyway? Network
failure certainly, but would a 'Not found' be considered a failure
that would cause it to move on? Would anything other than an ACK be a
failure?
If you receive a SIP response, than there is no transport failure ->
no failover to other SRV hosts.
1:49 p.m.
Mikael Magnusson wrote:
Klaus Darilion wrote:
sounds reasonable :-)
thanks
klaus
If you receive a SIP response, than there is no transport failure ->
no failover to other SRV hosts.
The next SRV record should be tried if a 503 "Service Unavailable" SIP
response message is received, according to RFC3263 section 4.3.
6891
days inactive
6892
days old
6 comments
5 participants
participants (5)
-
Bogdan-Andrei Iancu -
Daryl Sanders -
Douglas Garstang -
Klaus Darilion -
Mikael Magnusson