16 Oct
2007
16 Oct
'07
1:40 p.m.
Hi all,
I tried to implement redundancy with SRV records configured with different
priority and same weight.
If I register the client on the first proxy and then I stop OpenSER on it,
the client continues to send requests to the first proxy. Only after sending
about ten requests to first proxy it switches on the second proxy. Is it
normal?
Thanks.
Regards,
Antonio.
16 Oct
16 Oct
1:55 p.m.
El Tuesday 16 October 2007 15:40:19 Antonio Reale escribió:
Hi all,
I tried to implement redundancy with SRV records configured with different
priority and same weight.
If I register the client on the first proxy and then I stop OpenSER on it,
the client continues to send requests to the first proxy. Only after
sending about ten requests to first proxy it switches on the second proxy.
Is it normal?
I think so.
Note that DNS redundancy is not an instantant failover since client software
implements DNS cache, maybe a DNS proxy in the LAN, etc...
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
3:29 p.m.
Ok, thanks.
So what happen if a call starts on the first proxy, OpenSER on the first
proxy goes down and one of the clients close the call?
If the client sends the BYE on the second OpenSER, the proxy is able to
associate it with the correct call (for example for accounting purpose)?
--
Antonio.
-----Messaggio originale-----
Da: users-bounces(a)openser.org [mailto:users-bounces@openser.org] Per conto
di Iñaki Baz Castillo
Inviato: martedì 16 ottobre 2007 15.55
A: users(a)openser.org
Oggetto: Re: [OpenSER-Users] SRV records
El Tuesday 16 October 2007 15:40:19 Antonio Reale escribió:
Hi all,
I tried to implement redundancy with SRV records configured with different
priority and same weight.
If I register the client on the first proxy and then I stop OpenSER on it,
the client continues to send requests to the first proxy. Only after
sending about ten requests to first proxy it switches on the second proxy.
Is it normal?
I think so.
Note that DNS redundancy is not an instantant failover since client software
implements DNS cache, maybe a DNS proxy in the LAN, etc...
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
3:51 p.m.
El Tuesday 16 October 2007 17:29:06 Antonio Reale escribió:
Ok, thanks.
Note that in a DNS SRV query the client gets all the entries (as in any other
DNS query) so it his responsability to query the second alternative
(priority&weight) if the first doesn't response.
But there is ystem DNS cache and so...
So what happen if a call starts on the first proxy,
OpenSER on the first
proxy goes down and one of the clients close the call?
If the client sends the BYE on the second OpenSER, the proxy is able to
associate it with the correct call (for example for accounting purpose)?
Remember: OpenSer is not dialog aware (except using "dialog" module, but
it's
not the purpose).
OpenSer is just transactions aware. In a simple dialog there are at least
those transactions:
- INVITE (from caller to called) and responses 100, 180, 200.
- ACK (from caller to called)
- BYT (from caller to called) and response 200.
All these 3 transactions becomes a dialog JUST in the endpoints (phones), but
for OpenSer they are completely INDEPENDENT transactions.
I recomend you study it a lot since it's vital:
http://www.switzernet.com/people/emin-gabrielyan/070410-SIP-transactions/
http://4z.com/people/emin-gabrielyan/public/070412-SIP-record-route/
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
5:09 p.m.
Iñaki Baz Castillo wrote:
...
Remember: OpenSer is not dialog aware (except using "dialog" module, but
it's
not the purpose).
OpenSer is just transactions aware. In a simple dialog there are at least
those transactions:
- INVITE (from caller to called) and responses 100, 180, 200.
- ACK (from caller to called)
- BYT (from caller to called) and response 200.
All these 3 transactions becomes a dialog JUST in the endpoints (phones), but
for OpenSer they are completely INDEPENDENT transactions.
I recomend you study it a lot since it's vital:
http://www.switzernet.com/people/emin-gabrielyan/070410-SIP-transactions/
http://4z.com/people/emin-gabrielyan/public/070412-SIP-record-route/
Indeed, another website to consider is tech-invite.com. E.g.
http://tech-invite.com/Ti-sip-dialog.html
explains what a SIP dialog is and shows how such a dialog is created and
terminated.
And if you think this is complicated, have a look at
http://tech-invite.com/Ti-ims-sesflow-1.html ;-)
/Christian
17 Oct
17 Oct
9:38 a.m.
Thanks for pointing me to these useful links.
Regards.
--
Antonio
Iñaki Baz Castillo wrote:
I recomend you study it a lot since it's vital:
http://www.switzernet.com/people/emin-gabrielyan/070410-SIP-transactions/
http://4z.com/people/emin-gabrielyan/public/070412-SIP-record-route/
Christian Schlatter wrote:
Indeed, another website to consider is
tech-invite.com. E.g.
http://tech-invite.com/Ti-sip-dialog.html
explains what a SIP dialog is and shows how such a dialog is created
and terminated.
And if you think this is complicated, have a look at
http://tech-invite.com/Ti-ims-sesflow-1.html ;-)
/Christian
6117
days inactive
6118
days old
5 comments
3 participants
participants (3)
-
Antonio Reale -
Christian Schlatter -
Iñaki Baz Castillo