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.
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...
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)?
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 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
Thanks for pointing me to these useful links. Regards.
-
Antonio Reale -
Christian Schlatter -
Iñaki Baz Castillo