Subject: [sipcore] ECO(energy-saving) device and response code

From: Shida Schubert <[email-masked]>
Date: Tue, 22 Jun 2010 14:10:47 +0900

We have a device from several vendors on our test bed (and 
will be deployed in near future) that goes into sleep mode 
(energy saving mode) when standing by. 

 It takes about 10 seconds for these devices to wake up and 
although it can't process the SDP and other parameters in 
INVITE while resuming, it can be configured to send a 
response. 

 Question is what response should be sent to 
indicate to the caller the following semantics.

 "device on the callee side is waking up to decide 
whether it can handle the call or if it's interested in 
picking up the call at all". 

 The response code that kind of match the semantic 
is the 182 "Queued", based on the definition in RFC3261 
or 183 "Session Progress" but we can't seem to come to 
agreement internally, so I was hoping to get some opinions 
on this.. 

**

 21.1.4 182 Queued

   The called party is temporarily unavailable, but the server has
   decided to queue the call rather than reject it.  When the callee
   becomes available, it will return the appropriate final status
   response.  The reason phrase MAY give further details about the
   status of the call, for example, "5 calls queued; expected waiting
   time is 15 minutes".  The server MAY issue several 182 (Queued)
   responses to update the caller about the status of the queued call.  

**

 If none of the currently defined response code is 
suitable semantically, would it be viable to define a new 
response code for this, I personally don't think so but 
as we may see more and more of devices like this in the 
future, may be?
 
 Another option is I guess is to use current 18x + Alert-Info URN to 
indicate what's happening on the callee side.

 Regards
  Shida

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jun 2010 07:33:18 +0200

Hi Shida,

Without having an opinon which response code would be the most appropriate, please keep in mind that a 18x response does create an early dialog, so even if the terminal maybe doesn't need to process SDP at that point it may have create a route set etc.

Regards,

Christer 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Shida Schubert
> Sent: 22. kesäkuuta 2010 8:11
> To: SIPCORE
> Subject: [sipcore] ECO(energy-saving) device and response code
> 
> 
> INVITE while resuming, it can be configured to send a response. 
> 
>  Question is what response should be sent to indicate to the 
> caller the following semantics.
> 
>  "device on the callee side is waking up to decide whether it 
> can handle the call or if it's interested in picking up the 
> call at all". 
> 
>  The response code that kind of match the semantic is the 182 
> "Queued", based on the definition in RFC3261 or 183 "Session 
> Progress" but we can't seem to come to agreement internally, 
> so I was hoping to get some opinions on this.. 
> 
> **
> 
>  21.1.4 182 Queued
> 
>  If none of the currently defined response code is suitable 
> semantically, would it be viable to define a new response 
> code for this, I personally don't think so but as we may see 
> more and more of devices like this in the future, may be?
>  
>  Another option is I guess is to use current 18x + Alert-Info 
> URN to indicate what's happening on the callee side.
> 
>  Regards
>   Shida
> 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Jun 2010 09:32:03 -0400

Maybe the safest/simplest approach would be to simply send a 100 Trying.

	Thanks,
	Paul

---

From: Brett Tate <[email-masked]>
Date: Tue, 22 Jun 2010 06:46:30 -0700

I agree with Paul; however some callers might not like the delay before receiving a progression notice.  Thus something better (like a 183) may be needed.

In case you also needed something similar for non INVITE requests, RFC 4320 imposes some 1xx restrictions.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Tuesday, June 22, 2010 9:32 AM
> To: Christer Holmberg
> Cc: SIPCORE
> Subject: Re: [sipcore] ECO(energy-saving) device and response code
>

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Tue, 22 Jun 2010 15:57:10 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Shida Schubert [[email-masked]]

100 or 183 Call Progress seems best.   182 Queued suggests that there is an actual queue and the UA might be expected to tell something about the queue.  (Although that could be faked easily enough.)  100 ought to be adequate; it would quench resends and prevent rolling over to alternative destinations.  Would the UAC be disturbed by the 10 sec delay between the 100 and the first non-trivial response?

When you say the device "can't process the SDP", I assume that it can store the INVITE for processing when the device wakes up.  Indeed, your choice of actions might be limited by what the device is capable of while sleeping.

Dale

---

From: Shida Schubert <[email-masked]>
Date: Thu, 24 Jun 2010 18:05:51 +0900

Thanks for the feedback guys. 

 As far as I know we couldn't use 100 Trying because the 
Home-GW at our subscriber's home forks the INVITE 
to all the registered devices and if it doesn't 
get any 1xx(EXCEPT 100) or 2xx within 5 seconds, it 
CANCELS all the branches and sends back an error 
response. The reason the CANCEL procedure takes place 
after 5 seconds is because there may be call-forward/diversion/
voicemail set up for that subscriber. Furthermore sending no 
indication for 10 seconds seems tad bit unfriendly.. 
  
 Anyways, I guess defining a new status code is out of 
question as people are suggesting the use of 183. 

 Thanks again.
  Shida

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 24 Jun 2010 17:07:21 +0800

One must ask the question why a device has to be so dormant as to take 10 seconds to wake up Shida. 10 seconds is almost an eternity in the digital age.

Cheers
James

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Shida Schubert [[email-masked]]
Sent: Thursday, June 24, 2010 4:05 AM
To: WORLEY, Dale R (Dale)
Cc: SIPCORE
Subject: Re: [sipcore] ECO(energy-saving) device and response code

 Thanks again.
  Shida

---

From: Adam Roach <[email-masked]>
Date: Thu, 24 Jun 2010 10:01:03 -0500

> question as people are suggesting the use of 183.

[as participant]

I'm not sure that's the conclusion you should draw. Sure, 183 will 
probably work, but it was really intended more for "we're interworking 
with some other network, and it's told us about some form of progress 
that doesn't map into any of the SIP provisional responses."

It seems reasonable to define something like a "184 Waking Up" status 
code that informs whatever is upstream that you can't really answer 
right now, but should be able to in a few seconds. You might even throw 
in a new header field that informs the UAC how long it should take to 
get a better response to them; a forking proxy could take this value 
into account when it make decisions (regarding things like serial 
forking, etc).

I suspect that your situation is the first of many that will involve SIP 
and extremely low power devices, and that handling these kinds of 
situations gracefully will probably be very important in the next few years.

/a

---

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 24 Jun 2010 15:36:18 -0400

________________________________________
From: Shida Schubert [[email-masked]]

 Anyways, I guess defining a new status code is out of
question as people are suggesting the use of 183.
_______________________________________

I agree with Adam that these issues are probably going to be of interest to many implementations over the long term.

I would not exclude defining a new 18x code.  In theory, any non-100 1xx code should have the same effect as any other for this sort of purpose, and everybody expects that 18x codes describe call progress.  So (e.g.) 184 should not confuse any existing device.  The question is whether we want to distinguish 183 "Call Progress" from this situation.  As Adam notes, we may want to standardize an indication of how long it will be before a "real" provisional response comes.  ("Expires" header?)

I'm more curious about the behavior of your device, having worked on "fallback" problems in sipXecs.  In sipXecs, any destination has about 2.5 seconds to provide a 100 response (or some other response) before it is declared nonresponding and the call rolls over to the next destination in the RFC 3263 set or the next fork.  But once the 100 is seen, the destination is assumed live and is given the full expiration time to provide a 2xx response.  (And if it does not, no other RFC 3263 destination is tried, but we go on to the next fork.)

In your device, a 100 response isn't sufficient for the device to be considered live, and it's not clear to me why that is.  Conversely, if the device can wake up and provide a 184 response, the user may still not answer and the call could progress to diverted destinations.  So it doesn't seem to me that you're going to get the effect you want unless there are further complications that you haven't described (such as the device won't send 100 if it knows that the user has set call-forwarding).

Dale