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 . ;
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
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Klaus Darilion wrote:
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.
The next SRV record should be tried if a 503 "Service Unavailable" SIP response message is received, according to RFC3263 section 4.3.
/Mikael
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:
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.
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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:
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.
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Mikael Magnusson wrote:
Klaus Darilion wrote:
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.
sounds reasonable :-)
thanks klaus
-
Bogdan-Andrei Iancu -
Daryl Sanders -
Douglas Garstang -
Klaus Darilion -
Mikael Magnusson