#832 Battery life: STUN query frequency , SIP Register timeout

[Anonymous]

Originally created by: vale...@gmail.com

Proposal of improvement.

1. STUN query approximately sends every 2 minutes
Why they sending so frequently? It can be send once, on event - network connection established. Or make this value configurable.

2. SIP Register timeout 5 minutes.
Why so frequently? Desktop applications have higher value. Can you make this value configurable and higher by default, for example 1800 sec?

3. Why do not send register query with auth immediately, do not try to register without login?

Battery life is very important in such applications.

Thank you.

[Anonymous]

Originally posted by: vale...@gmail.com

> 2. SIP Register timeout 5 minutes.
Canceled. Found that it can be changed in Expert mode.

> 3. Why do not send register query with auth immediately
Canceled. I think this is impossible.

[Anonymous]

Originally posted by: r3gis...@gmail.com

About stun your absolutely right. In fact it's cause of the current design of the pjsip stack CSipSimple is relying on.
As the stack start stun resolution at startup it mean it is always on (and RFC specify this frequency). Indeed that's very bad in mobile context. pjsip-2.0 which is currently in development by the pjsip team and will bring many other features (such as video) should start stun only when really needed (just before a call).
It will also allow to have a stun server per account which is a better idea.

About the SIP register.. well you found the expert mode setting :) . However, just some additional information : I've recently changed the default value to increase it + there is something you have to be aware of :
If CSipSimple is not allowed to use 3G, it will not be able to de-register when wifi goes down. As consequence if your server allow multiple registartions it can lead to multiple registers at the same time for your client. Reducing re-registration timeout helps in this case.

If you want to learn more about battery consumption and contribute with your ideas you can continue on the issue 81. (Issue 81 is still open cause of the fact STUN in pjsip 1.x is started at startup ;) ... so exactly why this issue should remain open).
Do not hesitate if you have ideas. You can also have a look to the code and contribute reviews, it will be welcome ;).

Mergedinto: 81
Status: Duplicate