Hi,
We'd like to make a failover system using openser, DNS SRV records seems like a good idea, for failover and load balancing.
But it would be nice if, we could share or replicate SIP dialogs between opnser instances. UAs should send all messages to more proxys, and if one proxy die, the dialog should by handled by an other one. Example: -UA send an INVITE to proxy1 -proxy1 die -UA send the BYE at the end of the session to proy2, which could match this dialog, because it maintance the states of the dialogs too.
Is is possible?
Thanks!
Tomi
If you use only transaction statefulness (the only stateful mode the stable branch of OpenSER can do), this should not be a problem, as the INVITE and BYE messages are separate transactions. If you account to the same backend, you should maintain accounting consistency, too.
---Mike
-----Original Message----- From: users-bounces@openser.org on behalf of Cseke Tamas Sent: Tue 5/9/2006 3:43 AM To: users@openser.org Subject: [Users] failover
Hi,
We'd like to make a failover system using openser, DNS SRV records seems like a good idea, for failover and load balancing.
But it would be nice if, we could share or replicate SIP dialogs between opnser instances. UAs should send all messages to more proxys, and if one proxy die, the dialog should by handled by an other one. Example: -UA send an INVITE to proxy1 -proxy1 die -UA send the BYE at the end of the session to proy2, which could match this dialog, because it maintance the states of the dialogs too.
Is is possible?
Thanks!
Tomi
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Mike Williams wrote:
If you use only transaction statefulness (the only stateful mode the stable branch of OpenSER can do), this should not be a problem, as the INVITE and BYE messages are separate transactions. If you account to the same backend, you should maintain accounting consistency, too.
---Mike
That means, if one proxy dies during the session, the UA'll make a DNS SRV lookup, find the other proxy, and send the BYE to it instead of the proxy, which served the INVITE? Beacause of openser is only transaction stateful it don't know nothing about the session eg: to which INVITE belongs to this BYE? I planned to use TM module t_replicate function to replicate all messages to all proxy, it 's no sense, if openser doesn't maintain the states of dialog, isn't it?
Thanks, Tamas
Hi Cseke,
Cseke Tamas wrote:
Mike Williams wrote:
If you use only transaction statefulness (the only stateful mode the stable branch of OpenSER can do), this should not be a problem, as the INVITE and BYE messages are separate transactions. If you account to the same backend, you should maintain accounting consistency, too.
---Mike
That means, if one proxy dies during the session, the UA'll make a DNS SRV lookup, find the other proxy, and send the BYE to it instead of the proxy, which served the INVITE?
not quite - all sequential request (within the dialog) are routed based on the route set (the Record Route hdr added by the proxies on the path). The headers contains IP addresses, so basically no DNS lookup is done for sequential requests. An alternative will be to configure your proxy to put DNS name instead of IP in the RR hdr.
Beacause of openser is only transaction stateful it don't know nothing about the session eg: to which INVITE belongs to this BYE?
right
I planned to use TM module t_replicate function to replicate all messages to all proxy, it 's no sense, if openser doesn't maintain the states of dialog, isn't it?
right
regards, bogdan
Maybe the new dialog module can be used to store state of dialogs in shared storage (e.g. DB)...
On 5/9/06, Bogdan-Andrei Iancu bogdan@voice-system.ro wrote:
Hi Cseke,
Cseke Tamas wrote:
Mike Williams wrote:
If you use only transaction statefulness (the only stateful mode the stable branch of OpenSER can do), this should not be a problem, as the INVITE and BYE messages are separate transactions. If you account to the same backend, you should maintain accounting consistency, too.
---Mike
That means, if one proxy dies during the session, the UA'll make a DNS SRV lookup, find the other proxy, and send the BYE to it instead of the proxy, which served the INVITE?
not quite - all sequential request (within the dialog) are routed based on the route set (the Record Route hdr added by the proxies on the path). The headers contains IP addresses, so basically no DNS lookup is done for sequential requests. An alternative will be to configure your proxy to put DNS name instead of IP in the RR hdr.
Beacause of openser is only transaction stateful it don't know nothing about the session eg: to which INVITE belongs to this BYE?
right
I planned to use TM module t_replicate function to replicate all messages to all proxy, it 's no sense, if openser doesn't maintain the states of dialog, isn't it?
right
regards, bogdan
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Hi Bogdan,
That means, if one proxy dies during the session, the UA'll make a DNS SRV lookup, find the other proxy, and send the BYE to it instead of the proxy, which served the INVITE?
not quite - all sequential request (within the dialog) are routed based on the route set (the Record Route hdr added by the proxies on the path). The headers contains IP addresses, so basically no DNS lookup is done for sequential requests. An alternative will be to configure your proxy to put DNS name instead of IP in the RR hdr.
I 'd like the UAs to make only DNS lookup, when one proxy fails, if the proxy put domain name in The RR header, the UA must do a DNS lookup in every request, isn't it? And it could occur that transactions in a dialog would be sent to different proxys, even if it isn't nessecarry?
Would be nice, if the transaction target would change, only for failover reason.
example.com
_sip._udp IN SRV 0 1 5060 server1.example.com _sip._udp IN SRV 0 2 5060 server2.example.com
server1.example.com IN A 128.59.26.1 server2.example.com IN A 128.59.26.2
UA lookup SRV,and reaches server1. server1 want to stay in the signaling path, (Record-Route: sip:128.59.26.1) during the session server1 fails, when the message should be sent to server2. The UA try server2 or give up and the BYE never will be sent to any server?
Thanks, Tamas
see inline...
2006/5/9, Cseke Tamas cseke.tamas@eworldcom.hu:
Hi Bogdan,
That means, if one proxy dies during the session, the UA'll make a DNS SRV lookup, find the other proxy, and send the BYE to it instead of the proxy, which served the INVITE?
not quite - all sequential request (within the dialog) are routed based on the route set (the Record Route hdr added by the proxies on the path). The headers contains IP addresses, so basically no DNS lookup is done for sequential requests. An alternative will be to configure your proxy to put DNS name instead of IP in the RR hdr.
I 'd like the UAs to make only DNS lookup, when one proxy fails, if the proxy put domain name in The RR header, the UA must do a DNS lookup in every request, isn't it?
It should be (that's why it's always recommended to use FQDNs instead of IPs in SIP headers).....but I bet thousands of beers that many UAs won't do SRV lookup for every message.
And it could occur that transactions in a dialog would be sent to different proxys, even if it isn't nessecarry?
As long as request-response reaches the same proxy, it's ok to use different openSERs...be carefull with the database backend so you do not have different contacts for the same user...take a look at cacheless mode of operation.
Would be nice, if the transaction target would change, only for failover reason.
example.com
_sip._udp IN SRV 0 1 5060 server1.example.com _sip._udp IN SRV 0 2 5060 server2.example.com
server1.example.com IN A 128.59.26.1 server2.example.com IN A 128.59.26.2
UA lookup SRV,and reaches server1. server1 want to stay in the signaling path, (Record-Route: sip:128.59.26.1) during the session server1 fails, when the message should be sent to server2. The UA try server2 or give up and the BYE never will be sent to any server?
It completely depends on UA implementation....that's the problem of SRV failover. Some of them would do it properly and some of them will return error messages to users (just guessing from experience).
Thanks, Tamas
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
You could also try to set up a dispatcher as load balancer and a farm of openser behind.......
Samuel.
Hi,
2006/5/9, Cseke Tamas cseke.tamas@eworldcom.hu:
That means, if one proxy dies during the session, the UA'll make a DNS SRV lookup, find the other proxy, and send the BYE to it instead of the proxy, which served the INVITE?
not quite - all sequential request (within the dialog) are routed based on the route set (the Record Route hdr added by the proxies on the path). The headers contains IP addresses, so basically no DNS lookup is done for sequential requests. An alternative will be to configure your proxy to put DNS name instead of IP in the RR hdr.
I 'd like the UAs to make only DNS lookup, when one proxy fails, if the proxy put domain name in The RR header, the UA must do a DNS lookup in every request, isn't it?
It should be (that's why it's always recommended to use FQDNs instead of IPs in SIP headers).....but I bet thousands of beers that many UAs won't do SRV lookup for every message.
First of all thanks the replies! Problem is the same, i wanna send a transaction to another proxy if one dies. But a RR header for the whole dialog is valid, i've got a suggestion to use FQDNs... I quess this way it should work, please someone take a look, if i missunderstood something...
In the scenario there is 4 outbound proxy, the message will be send in the so called SIP trapezoid (UAC->Outbound proxy -> Inbound proxy -> UAS) The INVITE transaction is sent successfully to one outbound proxy, but this proxy goes down, and the BYE transaction should go to another proxy in the same dialog.
DNS SRV for failover and load balancing
_sip._udp IN SRV 0 6 proxy1.outboundproxydomain.com _sip._udp IN SRV 0 4 proxy2.outboundproxydomain.com _sip._udp IN SRV 1 6 proxy3.outboundproxydomain.com _sip._udp IN SRV 1 4 proxy4.outboundproxydomain.com
Address records
outboundproxydomain.com A 217.xxx.xxx.195 outboundproxydomain.com A 217.xxx.xxx.196 outboundproxydomain.com A 217.xxx.xxx.197 outboundproxydomain.com A 217.xxx.xxx.198
proxy1.outboundproxydomain.com A 217.xxx.xxx.195 proxy2.outboundproxydomain.com A 217.xxx.xxx.196 proxy3.outboundproxydomain.com A 217.xxx.xxx.197 proxy4.outboundproxydomain.com A 217.xxx.xxx.198
INVITE ______
UAC INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@domain.com
DNS lookup for outbound proxy (dig -t SRV _sip._udp.outboundproxydomain.com) Choose proxy1.outboundproxydomain.com dig -t A proxy1.outboundproxydomain.com -> 217.xxx.xxx.195 Send message to 217.xxx.xxx.195
Outbound proxy(217.xxx.xxx.195)
INVITE sip:callee@domain.com SIP/2.0 Record-Route: sip:outboundproxydomain.com;lr Contact: sip:caller@domain.com
Record-route ONLY its domain name. Lookup inbound proxy, send message to it.
Inbound proxy
INVITE sip:callee@domain.com SIP/2.0 Record-Route: <sip:proxy.domain.com Record-Route: sip:outboundproxydomain.com;lr Contact: sip:caller@domain.com
UAS
INVITE sip:callee@domain.com SIP/2.0 Record-Route: <sip:proxy.domain.com Record-Route: sip:outboundproxydomain.com;lr Contact: sip:caller@domain.com
....
BYE ___
UAC BYE sip:callee@domain.com SIP/2.0 Route: sip:outboundproxydomain.com;lr Route: sip:proxy.domain.com;lr Contact: sip:caller@domain.com
Most important part!!! lookup proxy (dig -t A outboundproxydomain.com) 217.xxx.xxx.195 failed send message 217.xxx.xxx.196 (proxy2.outboundproxydomain.com)
Outbound proxy (217.xxx.xxx.196):
BYE sip:callee@domain.com SIP/2.0 Route: sip:proxy.domain.com;lr Contact: sip:caller@domain.com
Inbound proxy:
BYE sip:callee@domain.com SIP/2.0 Contact: sip:caller@domain.com
UAS
BYE sip:callee@domain.com SIP/2.0 Contact: sip:caller@domain.com
Thanks in advance, Tamas
-
Bogdan-Andrei Iancu -
Cseke Tamas -
JF -
Mike Williams -
samuel