Hi, I have a scenario in which I have a little bit of confusion..
I have a redundant setup, two OpenSER, a MySQL cluster and replication of REGISTERs.
The UAC sends expires=3600 Both OpenSER's has a max_expires=1800, min_expires=300,default_expires=300
My Sipura-1001 has default expires=3600.
In the OK message sent from the OpenSER handeling the REGISTER, expires=1800 is sent back to the UAC which is OK (However the Sipura does not obey this, which also is struggeling, but that is another story....)
The replicated REGISTER, hovever, uses the original expiery from the UAC...expires=3600
Do I have to rewrite the expires in the replicated message?
Hi Helge,
REGISTRAR module updated only the reply information, without touching the request - usually, once got to the registrar, the path of the REGISTRAR ends, so no sense to update it.
In case of replication, it shouldn't be a problem if you set same expire limitation on both servers. The backup registrar will apply same limitations - just check via reply generated by it.
Regarding the SIPURA - it's broken - you should send a bug report.
regards, bogdan
Helge Waastad wrote:
Hi, I have a scenario in which I have a little bit of confusion..
I have a redundant setup, two OpenSER, a MySQL cluster and replication of REGISTERs.
The UAC sends expires=3600 Both OpenSER's has a max_expires=1800, min_expires=300,default_expires=300
My Sipura-1001 has default expires=3600.
In the OK message sent from the OpenSER handeling the REGISTER, expires=1800 is sent back to the UAC which is OK (However the Sipura does not obey this, which also is struggeling, but that is another story....)
The replicated REGISTER, hovever, uses the original expiery from the UAC...expires=3600
Do I have to rewrite the expires in the replicated message?
Thanks again, It true that the expires is the same on both after registration.
When it comes to sipura, I'm already in dialog with them....
(there should be somekind of certification checklist on sip phones....or maybe they should have the same bug all of them, at least it would be predictable ;-) )
Anyway, thanks alot.
br hw
On Fri, 2005-10-07 at 12:33 +0300, Bogdan-Andrei Iancu wrote:
Hi Helge,
REGISTRAR module updated only the reply information, without touching the request - usually, once got to the registrar, the path of the REGISTRAR ends, so no sense to update it.
In case of replication, it shouldn't be a problem if you set same expire limitation on both servers. The backup registrar will apply same limitations - just check via reply generated by it.
Regarding the SIPURA - it's broken - you should send a bug report.
regards, bogdan
Helge Waastad wrote:
Hi, I have a scenario in which I have a little bit of confusion..
I have a redundant setup, two OpenSER, a MySQL cluster and replication of REGISTERs.
The UAC sends expires=3600 Both OpenSER's has a max_expires=1800, min_expires=300,default_expires=300
My Sipura-1001 has default expires=3600.
In the OK message sent from the OpenSER handeling the REGISTER, expires=1800 is sent back to the UAC which is OK (However the Sipura does not obey this, which also is struggeling, but that is another story....)
The replicated REGISTER, hovever, uses the original expiery from the UAC...expires=3600
Do I have to rewrite the expires in the replicated message?
Hello,
On 10/07/05 13:09, Helge Waastad wrote:
Thanks again, It true that the expires is the same on both after registration.
When it comes to sipura, I'm already in dialog with them....
(there should be somekind of certification checklist on sip phones....or maybe they should have the same bug all of them, at least it would be predictable ;-) )
that's a good idea, I created a new topic on the dokuwiki (http://openser.org/dokuwiki/doku.php?id=sip_phones). Everybody is welcome to contribute. Please include the firmware version for each remark.
Cheers, Daniel
Anyway, thanks alot.
br hw
On Fri, 2005-10-07 at 12:33 +0300, Bogdan-Andrei Iancu wrote:
Hi Helge,
REGISTRAR module updated only the reply information, without touching the request - usually, once got to the registrar, the path of the REGISTRAR ends, so no sense to update it.
In case of replication, it shouldn't be a problem if you set same expire limitation on both servers. The backup registrar will apply same limitations - just check via reply generated by it.
Regarding the SIPURA - it's broken - you should send a bug report.
regards, bogdan
Helge Waastad wrote:
Hi, I have a scenario in which I have a little bit of confusion..
I have a redundant setup, two OpenSER, a MySQL cluster and replication of REGISTERs.
The UAC sends expires=3600 Both OpenSER's has a max_expires=1800, min_expires=300,default_expires=300
My Sipura-1001 has default expires=3600.
In the OK message sent from the OpenSER handeling the REGISTER, expires=1800 is sent back to the UAC which is OK (However the Sipura does not obey this, which also is struggeling, but that is another story....)
The replicated REGISTER, hovever, uses the original expiery from the UAC...expires=3600
Do I have to rewrite the expires in the replicated message?
Just to to throw oil on the fire: ;-)
If the SIP UA uses TCP, and the connection is reset, usually the port in the Contact URI changes. Thus, a new entry in the location table will be created.
This can be avoided using the call-id as identifier.
regards klaus
Daniel-Constantin Mierla wrote:
Hello,
On 10/07/05 13:09, Helge Waastad wrote:
Thanks again, It true that the expires is the same on both after registration.
When it comes to sipura, I'm already in dialog with them....
(there should be somekind of certification checklist on sip phones....or maybe they should have the same bug all of them, at least it would be predictable ;-) )
that's a good idea, I created a new topic on the dokuwiki (http://openser.org/dokuwiki/doku.php?id=sip_phones). Everybody is welcome to contribute. Please include the firmware version for each remark.
Cheers, Daniel
Anyway, thanks alot.
br hw
On Fri, 2005-10-07 at 12:33 +0300, Bogdan-Andrei Iancu wrote:
Hi Helge,
REGISTRAR module updated only the reply information, without touching the request - usually, once got to the registrar, the path of the REGISTRAR ends, so no sense to update it.
In case of replication, it shouldn't be a problem if you set same expire limitation on both servers. The backup registrar will apply same limitations - just check via reply generated by it.
Regarding the SIPURA - it's broken - you should send a bug report.
regards, bogdan
Helge Waastad wrote:
Hi, I have a scenario in which I have a little bit of confusion..
I have a redundant setup, two OpenSER, a MySQL cluster and replication of REGISTERs.
The UAC sends expires=3600 Both OpenSER's has a max_expires=1800, min_expires=300,default_expires=300
My Sipura-1001 has default expires=3600.
In the OK message sent from the OpenSER handeling the REGISTER, expires=1800 is sent back to the UAC which is OK (However the Sipura does not obey this, which also is struggeling, but that is another story....)
The replicated REGISTER, hovever, uses the original expiery from the UAC...expires=3600
Do I have to rewrite the expires in the replicated message?
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Ups! Sorry. I replied to the wrong thread. The message was meant for: Re: [Devel] Processing REGISTER requests
regards klaus
Klaus Darilion wrote:
Just to to throw oil on the fire: ;-)
If the SIP UA uses TCP, and the connection is reset, usually the port in the Contact URI changes. Thus, a new entry in the location table will be created.
This can be avoided using the call-id as identifier.
regards klaus
Daniel-Constantin Mierla wrote:
Hello,
On 10/07/05 13:09, Helge Waastad wrote:
Thanks again, It true that the expires is the same on both after registration.
When it comes to sipura, I'm already in dialog with them....
(there should be somekind of certification checklist on sip phones....or maybe they should have the same bug all of them, at least it would be predictable ;-) )
that's a good idea, I created a new topic on the dokuwiki (http://openser.org/dokuwiki/doku.php?id=sip_phones). Everybody is welcome to contribute. Please include the firmware version for each remark.
Cheers, Daniel
Anyway, thanks alot.
br hw
On Fri, 2005-10-07 at 12:33 +0300, Bogdan-Andrei Iancu wrote:
Hi Helge,
REGISTRAR module updated only the reply information, without touching the request - usually, once got to the registrar, the path of the REGISTRAR ends, so no sense to update it.
In case of replication, it shouldn't be a problem if you set same expire limitation on both servers. The backup registrar will apply same limitations - just check via reply generated by it.
Regarding the SIPURA - it's broken - you should send a bug report.
regards, bogdan
Helge Waastad wrote:
Hi, I have a scenario in which I have a little bit of confusion..
I have a redundant setup, two OpenSER, a MySQL cluster and replication of REGISTERs.
The UAC sends expires=3600 Both OpenSER's has a max_expires=1800, min_expires=300,default_expires=300
My Sipura-1001 has default expires=3600.
In the OK message sent from the OpenSER handeling the REGISTER, expires=1800 is sent back to the UAC which is OK (However the Sipura does not obey this, which also is struggeling, but that is another story....)
The replicated REGISTER, hovever, uses the original expiery from the UAC...expires=3600
Do I have to rewrite the expires in the replicated message?
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
On 10/10/05 11:25, Klaus Darilion wrote:
Just to to throw oil on the fire: ;-)
If the SIP UA uses TCP, and the connection is reset, usually the port in the Contact URI changes. Thus, a new entry in the location table will be created.
this should not happen. The UA should register the contact address where it listens. Same tcp connection is used generally just at transaction level, then it is closed by server. Keeping the tcp connections open for long time will overload the server.
Ideally, in this case, the UA unregisters the previous contact when it detects that it will register another contact address. When the UA does not follow some basic rules, it is hard to predict and handle all situations that can occur.
TCP and NAT will not work in most of the cases, and when there is no nat, the UA has no excuse to behave wrongly during registration.
Cheers, Daniel
This can be avoided using the call-id as identifier.
regards klaus
Daniel-Constantin Mierla wrote:
On 10/10/05 11:25, Klaus Darilion wrote:
Just to to throw oil on the fire: ;-)
If the SIP UA uses TCP, and the connection is reset, usually the port in the Contact URI changes. Thus, a new entry in the location table will be created.
this should not happen. The UA should register the contact address where it listens. Same tcp connection is used generally just at transaction level, then it is closed by server. Keeping the tcp connections open for long time will overload the server.
it happens: SNOM 360
Ideally, in this case, the UA unregisters the previous contact when it detects that it will register another contact address. When the UA does not follow some basic rules, it is hard to predict and handle all situations that can occur.
I would be nice if a phone would do this, but I do not think TCP implementations are better than UDP implementations.
TCP and NAT will not work in most of the cases, and when there is no nat, the UA has no excuse to behave wrongly during registration.
If I would implement a SIP client using TCP the client would: - open the TCP connection - send keep alive (CRLF) - if the connection is terminated by the proxy or there is a delivery failure the client would immediately reconnect to the proxy.
IMO a SIP proxy should be able to keep >thousand TCP sessions open
regards klaus
Cheers, Daniel
This can be avoided using the call-id as identifier.
regards klaus
On 10/10/05 17:42, Klaus Darilion wrote:
Daniel-Constantin Mierla wrote: [...]
TCP and NAT will not work in most of the cases, and when there is no nat, the UA has no excuse to behave wrongly during registration.
If I would implement a SIP client using TCP the client would:
- open the TCP connection
- send keep alive (CRLF)
- if the connection is terminated by the proxy or there is a delivery
failure the client would immediately reconnect to the proxy.
I am not sure if this helps in any meaning, since most of the servers will open a new connection when the call comes towards the tcp user. Otherwise, the registrar must keep the tcp connection id in the usrloc database which will not be valid upon a restart or close+re-connection. Going through all tcp connection opened in the server to figure out if it is one linking the user, may be more time consuming that opening a new one. Since I have not tested tcp too much in my environment, I do not know how specific nat situations can be dealt.
IMO a SIP proxy should be able to keep >thousand TCP sessions open
I agree, but if they are no longer useful for the server, makes no much sense to keep them, in my opinion.
Cheers, Daniel
regards klaus
Cheers, Daniel
This can be avoided using the call-id as identifier.
regards klaus
Hi Daniel!
The more I use UDP for SIP the less I like it: - it is spoofable - many NATs are insecure (except symmetric NAT) - SIP packets for growing with new features, headers, codecs ... thus fragmentation is an issue
IMO TCP is much more secure. For NAT traversal of course it also requires keep alive and the session must be kept open to allow incoming calls.
I'm not familiar with opensers TCP part, but I thought that requests the the SIP clients will always be routed through existing TCP connections. Wouldn't it be possible to store a socked id in the location table to avoid searching for the existing TCP connection.
Lots of people argue that keeping the TCP connections open is bad and puts heavy load on the server. I also saw some other statements that thousands of TCP connection is no problem on Unix (Solaris, BSD).
Are there some people having experience with SIP+TCP or thousands of TCP connections on one server? Please speak now.
regards klaus
Daniel-Constantin Mierla wrote:
On 10/10/05 17:42, Klaus Darilion wrote:
Daniel-Constantin Mierla wrote: [...]
TCP and NAT will not work in most of the cases, and when there is no nat, the UA has no excuse to behave wrongly during registration.
If I would implement a SIP client using TCP the client would:
- open the TCP connection
- send keep alive (CRLF)
- if the connection is terminated by the proxy or there is a delivery
failure the client would immediately reconnect to the proxy.
I am not sure if this helps in any meaning, since most of the servers will open a new connection when the call comes towards the tcp user. Otherwise, the registrar must keep the tcp connection id in the usrloc database which will not be valid upon a restart or close+re-connection. Going through all tcp connection opened in the server to figure out if it is one linking the user, may be more time consuming that opening a new one. Since I have not tested tcp too much in my environment, I do not know how specific nat situations can be dealt.
IMO a SIP proxy should be able to keep >thousand TCP sessions open
I agree, but if they are no longer useful for the server, makes no much sense to keep them, in my opinion.
Cheers, Daniel
regards klaus
Cheers, Daniel
This can be avoided using the call-id as identifier.
regards klaus
On 10/06/05 17:23, Helge Waastad wrote:
Hi, I have a scenario in which I have a little bit of confusion..
I have a redundant setup, two OpenSER, a MySQL cluster and replication of REGISTERs.
The UAC sends expires=3600 Both OpenSER's has a max_expires=1800, min_expires=300,default_expires=300
My Sipura-1001 has default expires=3600.
In the OK message sent from the OpenSER handeling the REGISTER, expires=1800 is sent back to the UAC which is OK (However the Sipura does not obey this, which also is struggeling, but that is another story....)
The replicated REGISTER, hovever, uses the original expiery from the UAC...expires=3600
Do I have to rewrite the expires in the replicated message?
If you set the same parameters for registrar in the replicated server, then you do not need the rewrite the expires header.
Cheers, Daniel
-
Bogdan-Andrei Iancu -
Daniel-Constantin Mierla -
Helge Waastad -
Klaus Darilion