Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Outbound

From: Christer Holmberg <[email-masked]>
Date: Sat, 3 Feb 2018 12:02:18 +0000

Hi,

In order to cover Outbound, I suggest to enhance the following paragraph in the Introduction section:

OLD:

 "Due to the restriction above, applications can not be woken up by non-push  notification
 traffic. This means that a suspended SIP UA will not be able to receive an incoming 
 SIP request (e.g., a SIP INVITE request), or to send periodic re-registration requests."

NEW:

"Due to the restriction above, applications can not be woken up by non-push  notification
 traffic. This means that a suspended SIP UA will not be able to receive an incoming 
 SIP request (e.g., a SIP INVITE request), or to send periodic re-registration requests.
 Also, the SIP UA will not be able to maintain connections e.g., using the SIP Outbound
 Mechanism [REF-to-Outbound], as it requires the UA to send periodic keep-alive messages."

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Mon, 5 Feb 2018 10:59:30 +1100

Any advice on when one or the other might be preferred?  Keep-alive
doesn't make sense if you have an agreed push service.  Once a UA has
signaled support for a given system and the proxy has indicated
matching support, you could drop the keep-alives.

On Sat, Feb 3, 2018 at 11:02 PM, Christer Holmberg
<[email-masked]> wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Feb 2018 14:41:22 +0000

Hi,

>Any advice on when one or the other might be preferred?

SIP Push is for cases where internal timers can't be used in order to wake up suspended applications in order to send keep-alives etc.

Regards,

Christer

On Sat, Feb 3, 2018 at 11:02 PM, Christer Holmberg <[email-masked]> wrote:
>  "Due to the restriction above, applications can not be woken up by 
> non-push  notification  traffic. This means that a suspended SIP UA 
> will not be able to receive an incoming  SIP request (e.g., a SIP INVITE request), or to send periodic re-registration requests."
>
> NEW:
>
> "Due to the restriction above, applications can not be woken up by 
> non-push  notification  traffic. This means that a suspended SIP UA 
> will not be able to receive an incoming  SIP request (e.g., a SIP INVITE request), or to send periodic re-registration requests.
>  Also, the SIP UA will not be able to maintain connections e.g., using 
> the SIP Outbound  Mechanism [REF-to-Outbound], as it requires the UA to send periodic keep-alive messages."
>
> Regards,
>
> Christer
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 5 Feb 2018 11:21:12 -0500

Hi,

Even when clients can be woken up (there are ways to do this on all mobile
platforms, including IOS), waking up application with frequency required to
send SIP keep-alive messages leads to increased energy consumption. Extra
network messages, required for SIP keep-alive, also lead to higher energy
consumption. SIP Push greatly reduces the required energy consumption for
mobile clients, since it allows SIP clients to go for a suspended state for
long periods of time without sending any messages. SIP Push is often more
reliable then SIP Outbound since it does not require SIP client to maintain
a NAT binding when SIP call is not in progress. Furthermore, SIP Push
reduces the load on SIP Proxy since it reduces the number of network
messages SIP Proxy needs to process.

In general, it should be recommended to use SIP Push on mobile platforms
instead of SIP Outbound, when SIP Push is available.

Regards,
_____________
Roman Shpount

On Mon, Feb 5, 2018 at 9:41 AM, Christer Holmberg <
[email-masked]> wrote:

> SIP Push is for cases where internal timers can't be used in order to wake
> up suspended applications in order to send keep-alives etc.
>
> Regards,
>
> Christer
>
>
>
>
> > will not be able to receive an incoming  SIP request (e.g., a SIP INVITE
> request), or to send periodic re-registration requests."
> >
> > NEW:
> >
> > will not be able to receive an incoming  SIP request (e.g., a SIP INVITE
> request), or to send periodic re-registration requests.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 5 Feb 2018 19:31:27 +0000

Hi Roman,

We can for sure add some text about advantages (regarding battery life etc) of SIP Push with mobile terminals in general.

However, I think it is outside the scope of this document to make recommendations on what mechanisms to use.

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 05 February 2018 18:21
To: Christer Holmberg <[email-masked]>
Cc: Martin Thomson <[email-masked]>; [email-masked]
Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Outbound

Hi,

Even when clients can be woken up (there are ways to do this on all mobile platforms, including IOS), waking up application with frequency required to send SIP keep-alive messages leads to increased energy consumption. Extra network messages, required for SIP keep-alive, also lead to higher energy consumption. SIP Push greatly reduces the required energy consumption for mobile clients, since it allows SIP clients to go for a suspended state for long periods of time without sending any messages. SIP Push is often more reliable then SIP Outbound since it does not require SIP client to maintain a NAT binding when SIP call is not in progress. Furthermore, SIP Push reduces the load on SIP Proxy since it reduces the number of network messages SIP Proxy needs to process.

In general, it should be recommended to use SIP Push on mobile platforms instead of SIP Outbound, when SIP Push is available.

Regards,
_____________
Roman Shpount

On Mon, Feb 5, 2018 at 9:41 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

On Sat, Feb 3, 2018 at 11:02 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
sipcore mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 11:05:30 +1100

I don't care about the policy question (I agree with both of you there
- Roman that push is better, Christer that it is a policy decision).
What I care about is that we make it clear whether running both
options is acceptable.  Mostly, when a UA (or proxy) might reasonable
decide to turn off keep-alives.

On Tue, Feb 6, 2018 at 6:31 AM, Christer Holmberg
<[email-masked]> wrote:
> Hi Roman,
>
>
>
> We can for sure add some text about advantages (regarding battery life etc)
> of SIP Push with mobile terminals in general.
>
>
>
> However, I think it is outside the scope of this document to make
> recommendations on what mechanisms to use.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> On Mon, Feb 5, 2018 at 9:41 AM, Christer Holmberg

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 03:11:55 +0000

Hi,

>What I care about is that we make it clear whether running both options is acceptable.  Mostly, when a UA (or proxy) might reasonable decide to turn off keep-alives.

Technically one could of course run both options, but I see no point in doing so, so I think we could recommend against it, or even say SHOULD NOT.

Regards,

Christer

On Tue, Feb 6, 2018 at 6:31 AM, Christer Holmberg <[email-masked]> wrote:
> Hi Roman,
>
>
>
> We can for sure add some text about advantages (regarding battery life 
> etc) of SIP Push with mobile terminals in general.
>
>
>
> Even when clients can be woken up (there are ways to do this on all 
> mobile platforms, including IOS), waking up application with frequency 
> required to send SIP keep-alive messages leads to increased energy 
> consumption. Extra network messages, required for SIP keep-alive, also 
> lead to higher energy consumption. SIP Push greatly reduces the 
> required energy consumption for mobile clients, since it allows SIP 
> clients to go for a suspended state for long periods of time without 
> sending any messages. SIP Push is often more reliable then SIP 
> Outbound since it does not require SIP client to maintain a NAT 
> binding when SIP call is not in progress. Furthermore, SIP Push 
> reduces the load on SIP Proxy since it reduces the number of network messages SIP Proxy needs to process.
>
>
>
> In general, it should be recommended to use SIP Push on mobile 
> platforms instead of SIP Outbound, when SIP Push is available.
>
>
>
> Regards,
>
> _____________
> Roman Shpount
>
>
>
> SIP Push is for cases where internal timers can't be used in order to 
> wake up suspended applications in order to send keep-alives etc.
>
> Regards,
>
> Christer
>
>
>
>
>> will not be able to receive an incoming  SIP request (e.g., a SIP 
>> INVITE request), or to send periodic re-registration requests."
>>
>> NEW:
>>
>> will not be able to receive an incoming  SIP request (e.g., a SIP 
>> INVITE request), or to send periodic re-registration requests.
>>  Also, the SIP UA will not be able to maintain connections e.g., 
>> using the SIP Outbound  Mechanism [REF-to-Outbound], as it requires 
>> the UA to send periodic keep-alive messages."
>>
>> Regards,
>>
>> Christer
>>

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 05 Feb 2018 22:57:33 -0500

> matching support, you could drop the keep-alives.

Strictly speaking, both ends knowing that they support the same push
mechanism doesn't accomplish anything.  You mean to say "Once a UA has
successfully registered specifying a push notification service (section
4), it can discontinue registering using SIP Outbound."

Dale