News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

SIP registration

Started by OZOi, August 23, 2011, 02:43:54 PM

Previous topic - Next topic

OZOi

I have 3 simple (I hope) questions:
1. How to configure OBi100 to send REGISTER requests every 10 min?

2. How to make it send REGISTER requests containing common "Expires: 600" filed?

3. How to make it send Keep Alive packets to keep hole in NAT/firewall opened all the registration time?


And here is some points related to each question correspondingly:
1. To send REGISTER requests every 10 min I configured OBi100 (in "Service Providers | ITSP Profile A"):
RegistrationPeriod = 1100

Why it must be 1100 instead of 600 as expected? If it's set to 1100, OBi sends its next REGISTER request in 600 sec, instead of 1100 as specified. Keep in mind that SIP server may offer a grace period (usually 1 min) over the specified by SIP client time (1100 sec in this case) to keep registration active...

2. To include common "Expires: 600" filed I configured OBi100 (in "Service Providers | ITSP Profile A"):
RegisterExpires = 600

But there is no any "Expires: 600" filed in the REGISTER requests, sent by OBi100... Is it a bug?

3. If I configure OBi100 to send REGISTER requests every 10 min, I start loosing incoming calls (NAT/firewall closes its hole after a timeout since last REGISTER requests was sent). See perhaps related thread here.

I'm looking at some KeepAlive parameter here. SIP clients usually use KeepAlive. It's interval (in sec) between a ping-like packets, sent by SIP client to SIP server to keep the registration connection (formally it uses UDP, not a TCP connection) alive.

Does OBi support KeepAlive?


BTW, I think there is a small bug, not mentioned above. Every time OBi sends double REGISTER requests when it needs to register itself:
1. OBi sends one REGISTER request
2. gets "401 Unauthorized" back and ignores it
3. OBi sends second REGISTER request
4. gets "401 Unauthorized" back
5. OBi replies with new REGISTER request, now containing "Authorization:" data
6. OBi gets "200 OK"

Steps 1 and 2 are redundant and should be eliminated.

OZOi

OK, if there is no any response to my questions, I'd like to report bugs:

1. Option "Service Providers | ITSP Profile A | SIP | RegisterExpires" doesn't work at all.
You may try to change its value, but you won't see any result. There is no "Expires" header value in REGISTER requests.

What is expected:
The option sets REGISTER Expires header value in seconds.

2. Option "Service Providers | ITSP Profile A | SIP | RegistrationPeriod" doesn't work as expected.
If you set it, let say, to 1100 sec, OBi sends REGISTER requests every 600 sec, which doesn't make sense. If you set it 360, OBi sends register requests every 180 sec. Default value is 60 sec, but in this case, OBi registers itself every 30 sec.

What is expected:
The option sets interval between REGISTER requests in seconds. If it's set 600 seconds, SIP server should get next registration request in 600 sec (10 min) and not in less then 5 min (as it does now).

3. When user asks OBi to reboot, OBi does not un-registers itself form SIP server.
SIP server keeps account in registered state, while it actually becomes invalid.

What is expected:
Just before OBi shuts down - it should send to SIP server REGISTER request with "Expires=0" value. It will un-register account in SIP server.


Related points (not bugs):
1. Why by default OBi sends REGISTER requests every 30 sec? Isn't that way too excessive for a static device? It's not a smart phone, that may change its location/IP while it's moving. Sending REGISTER requests every 30 sec creates completely unnecessary traffic and makes debugging (reading logs) difficult.

2. OBi may benefit from a "Register" button in "Status | System Status" page, section "SPx Service Status". When user clicks on that button, it will trigger a new registration request sent to SIP server. It could be useful for tests and troubleshooting.

3. Two options "RegistrationPeriod" and "RegisterExpires", which are setting the same value ("Expires"), are confusing in configuration. Could you please consider redesign and offer just one...