[jitsi-dev] Sip Options keep alives and battery consumption on Android


#1

Hi,

There is a problem with SIP OPTIONS keep alives on Android that when
3G(mobile internet) is used the app doesn't receive responses to those
requests. The stack is doing retry attempts which results in massive
badwidth usage and battery consumption. This takes place only when UDP
transport method is used.

It happens for most providers, but not for everyone. What's strange is
that REGISTER keep alives will work. It looks like OPTIONS are
blocked. INFO requests are coming through. When 3G connection is
shared to the PC then the behaviour is the same - OPTIONS do not work.

Does anyone have any clue maybe ? For now we've decided to use empty
/r/n packets instead of OPTIONS when UDP is used on Android. I'm
attaching a patch for it and ask you for a review as I'm not too
familiar with SIP stuff. Here are my doubts:

1. ListeneningPointExt interface is used directly to send null request
with sendHeartbeat() method. It's instance is obtained from the
provider for UDP transport.

2. Address and port where the request will be sent is obtained from
ProxyConnection returned by provider.getConnection(). I'm not sure if
this will be the right address and port.

3. Null requests are not logged as part of packets capture, because
nist stack doesn't log them through ServerLogging interface. Just
wanted to mention this fact, but I guess we can live with that.

Best regards,
Pawel

null_request_keep_alive.patch (3.27 KB)


#2

Hey Pawel,

Hi,

There is a problem with SIP OPTIONS keep alives on Android that when
3G(mobile internet) is used the app doesn't receive responses to those
requests. The stack is doing retry attempts which results in massive
badwidth usage and battery consumption. This takes place only when UDP
transport method is used.

It happens for most providers, but not for everyone. What's strange is
that REGISTER keep alives will work. It looks like OPTIONS are
blocked. INFO requests are coming through. When 3G connection is
shared to the PC then the behaviour is the same - OPTIONS do not work.

Does anyone have any clue maybe ? For now we've decided to use empty
/r/n packets instead of OPTIONS when UDP is used on Android. I'm
attaching a patch for it and ask you for a review as I'm not too
familiar with SIP stuff. Here are my doubts:

Some comments on the patch:

* it is a common practice to also send /r/n on TCP connections. It's actually part of SIP OUBOUND:

http://tools.ietf.org/search/rfc5626

Doesn't the "sendHeartbeat()" method support TCP?

* Because this is a nice NAT traversal method in general, it would be good to make it available to the desktop as well, as one of the KA methods. That is, have it as a separate class, then simply use that as the preferred KA method on Android.

We just may want to make sure that this becomes the default for existing android accounts. I am open to suggestions.

* Make sure you handle the case of a registrarless connection. Obviously there would be no packet to send there but just make sure we don't hit an exception or anything

1. ListeneningPointExt interface is used directly to send null request
with sendHeartbeat() method. It's instance is obtained from the
provider for UDP transport.

Yes that's OK.

2. Address and port where the request will be sent is obtained from
ProxyConnection returned by provider.getConnection(). I'm not sure if
this will be the right address and port.

It will be, unless the connection is RegistrarLess in which case you shouldn't send anything.

Could you please make sure that this works with IPv6?

3. Null requests are not logged as part of packets capture, because
nist stack doesn't log them through ServerLogging interface. Just
wanted to mention this fact, but I guess we can live with that.

OK,

Emil

···

On 16.01.14, 11:32, Paweł Domas wrote:

Best regards,
Pawel

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

Hi Emil,

Some comments on the patch:

* it is a common practice to also send /r/n on TCP connections. It's
actually part of SIP OUBOUND:

http://tools.ietf.org/search/rfc5626

Doesn't the "sendHeartbeat()" method support TCP?

By looking at nist code it looks like yes, but I'm going to try this out.

* Because this is a nice NAT traversal method in general, it would be good
to make it available to the desktop as well, as one of the KA methods. That
is, have it as a separate class, then simply use that as the preferred KA
method on Android.

Ok, then how we will call this method ? Null request ? Does it have any name ?

We just may want to make sure that this becomes the default for existing
android accounts. I am open to suggestions.

This should be easily achieved through jitsi-default.properties

* Make sure you handle the case of a registrarless connection. Obviously
there would be no packet to send there but just make sure we don't hit an
exception or anything

1. ListeneningPointExt interface is used directly to send null request
with sendHeartbeat() method. It's instance is obtained from the
provider for UDP transport.

Yes that's OK.

2. Address and port where the request will be sent is obtained from
ProxyConnection returned by provider.getConnection(). I'm not sure if
this will be the right address and port.

It will be, unless the connection is RegistrarLess in which case you
shouldn't send anything.

Could you please make sure that this works with IPv6?

Sure, I will.

Regards,
Pawel

···

On Thu, Jan 16, 2014 at 6:04 PM, Emil Ivov <emcho@jitsi.org> wrote:


#4

Hi Emil,

Some comments on the patch:

* it is a common practice to also send /r/n on TCP connections. It's
actually part of SIP OUBOUND:

http://tools.ietf.org/search/rfc5626

Doesn't the "sendHeartbeat()" method support TCP?

By looking at nist code it looks like yes, but I'm going to try this out.

* Because this is a nice NAT traversal method in general, it would be good
to make it available to the desktop as well, as one of the KA methods. That
is, have it as a separate class, then simply use that as the preferred KA
method on Android.

Ok, then how we will call this method ? Null request ? Does it have any name ?

I like "heart beat". How about "/r/n heart beat" ?

We just may want to make sure that this becomes the default for existing
android accounts. I am open to suggestions.

This should be easily achieved through jitsi-default.properties

Right ... not sure that it would work for already installed accounts however, because we explicitly set this to OPTIONS there. Not sure if we should care about that.

* Make sure you handle the case of a registrarless connection. Obviously
there would be no packet to send there but just make sure we don't hit an
exception or anything

1. ListeneningPointExt interface is used directly to send null request
with sendHeartbeat() method. It's instance is obtained from the
provider for UDP transport.

Yes that's OK.

2. Address and port where the request will be sent is obtained from
ProxyConnection returned by provider.getConnection(). I'm not sure if
this will be the right address and port.

It will be, unless the connection is RegistrarLess in which case you
shouldn't send anything.

Could you please make sure that this works with IPv6?

Sure, I will.

Thanks!
Emil

···

On 17.01.14, 14:32, Paweł Domas wrote:

On Thu, Jan 16, 2014 at 6:04 PM, Emil Ivov <emcho@jitsi.org> wrote:

--
https://jitsi.org


#5

Obviously that's \r\n. Thanks Lyubo for the nudge!

Your mail actually made me realise a cooler option:

"CRLF heart beat"

That sound OK?

Emil

···

On 17.01.14, 17:58, Emil Ivov wrote:

I like "heart beat". How about "/r/n heart beat" ?

--
https://jitsi.org


#6

Hi Emil,

···

On Fri, Jan 17, 2014 at 6:40 PM, Emil Ivov <emcho@jitsi.org> wrote:

On 17.01.14, 17:58, Emil Ivov wrote:

I like "heart beat". How about "/r/n heart beat" ?

Obviously that's \r\n. Thanks Lyubo for the nudge!

Your mail actually made me realise a cooler option:

"CRLF heart beat"

That sound OK?

Emil

Yes, it is. Although the patch is quite easy to write I have
discovered one bug with SIP account when it's enabled/disabled from
the accounts list. I'm looking how to fix it and that's why it is
taking so long.

Best regards,
Pawel


#7

Hi Emil,

New version of the patch is ready. I think all discussed issues are
addressed except that I am unable to test it on ipv6 as my router
doesn't support it(will have to replace it).

Regards,
Pawel

crlf_keep_alive.patch (5.21 KB)


#8

Hi Emil,

I've fixed NPE in SipLogger when TCP transport is used as nist tries
to log CRLF packets(it doesn't on UDP).
It's tested and should be ready to commit. Eventually it will do no
harm on the desktop as it has to be enabled by the user anyway. We'll
test it extensively on Android, where it's the default method.

Regards,
Pawel

crlf_keep_alive.patch (6.16 KB)

···

On Mon, Jan 20, 2014 at 2:09 PM, Paweł Domas <pawel.domas@jitsi.org> wrote:

Hi Emil,

New version of the patch is ready. I think all discussed issues are
addressed except that I am unable to test it on ipv6 as my router
doesn't support it(will have to replace it).

Regards,
Pawel