9 May
2006
9 May
'06
4:43 a.m.
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
9 May
9 May
8:54 a.m.
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(a)openser.org on behalf of Cseke Tamas
Sent: Tue 5/9/2006 3:43 AM
To: users(a)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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
9:23 a.m.
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
10:23 a.m.
Hi Cseke,
Cseke Tamas wrote:
Mike Williams wrote:
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.
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?
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
10:53 a.m.
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(a)voice-system.ro> wrote:
Hi Cseke,
Cseke Tamas wrote:
Mike Williams wrote:
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.
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?
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(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
11:14 a.m.
Hi Bogdan,
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
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.
10 May
10 May
3:50 a.m.
see inline...
2006/5/9, Cseke Tamas <cseke.tamas(a)eworldcom.hu>hu>:
Hi Bogdan,
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.
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.
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(a)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.
15 May
15 May
6:12 a.m.
Hi,
2006/5/9, Cseke Tamas
<cseke.tamas(a)eworldcom.hu>hu>:
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
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.
6667
days inactive
6673
days old
7 comments
5 participants
participants (5)
-
Bogdan-Andrei Iancu -
Cseke Tamas -
JF -
Mike Williams -
samuel