Subject: [Sipping] SIP support for hold and ringback for operator / 911 services

From: "Xuewen Li" <[email-masked]>
Date: Sun, 15 Feb 2004 22:07:54 -0500

Has anyone looked into how the orig-hold and ringback function should be
supported in SIP?  I realize that the wording may not be fully inline with
the SIP model, but this is a real issue to address. 

Note that some of the terms below are in quotes since they are TDM telephony
terms but are used in this context to represent logical equivalent. For
example, "offhook" represents the action to initiate a call and "onhook"
represents the action to end the call.

Orig-hold refers to the ability to keep the call even when the originator
goes "onhook" before the operator releases the call. The 911 operator is
notified of such event (i.e., the caller has gone "onhook") so that the
operator can initiate ringback (a special physical ringing is applied.) When
the caller goes "offhook", no "dial tone" is provided. Rather the caller is
reconnected to the original call to the 911 operator.  

When the caller is served by a softswitch which is connected to the 911
tandem via a SIP interface, SIP support for such functionality is required.

Let's assume UA_a represents the caller, and UA_b represents the 911
operator.

CMSS has a DCS-OSPS header (tag value = RING) which provides the mechanism
for UA_b to request the "physical ringback".  However the following pieces
are missing.

1.    Some way to communicate the caller's capabilities, e.g., supports
orig-hold or not

2.    Some mechanism to allow UA_b to request UA_a to apply orig-hold for
this call.

3.    Some mechanism for UA_b to subscribe to UA_a's "onhook" or "offhook"
state changes.  One can argue whether or not these are session states...

4.    Some mechanism for UA_a to notify UA_b the state changes of UA_a

For item 1, will the ALLOW header be appropriate?

For item 2, the DCS-OSPS header (tagvalue=RING) can be used

For item 3 and 4, will the SUBSCRIBE / NOTIFY mechanism be appropriate? 

Any thoughts, comment?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Feb 2004 16:35:05 -0500

Here is my opinion FWIW.

You need to be careful how you define these services. You want to make 
sure they work and are sensible for a broad range of devices, including, 
for example, a PC application or a wireless phone, where there is no 
hook at all.

Firstly, I think it makes sense that, when the caller reaches 911, there 
is information in the 200 OK that indicates that the caller has reached 
an emergency service center. The callee capabilities framework would 
allow the 200 OK to INVITE to contain a parameter indicating this, for 
example, actor="emergency-center". When this is conveyed to the caller, 
the caller can take whatever UI action is necesary to indicate to them 
that they shouldnt try to hangup the call. Of course authentication is 
of the utmost importance here. Henning's emergency architecture draft 
alludes to such an indication but I didnt see any specific text on it.

Should the caller anyway send a BYE, the UAS (the emergency center) can 
reject that BYE with a new response code, to indicate that the call 
cannot be disconnected because its an emergency operator. This way, an 
automata would explicitly know that this was not some normal error, and 
that the UI should not be dismissed.

There is a temptation to try and add a state to the dialog event package 
so that the emergency operator can know that the caller is still trying 
to disconnect the call (ie, "on-hook"). This way, if the caller stops 
trying to disconnect, i.e., goes back "off-hook", the emergency service 
center would cease any attempts at interacting with the user to get them 
to pick up.

The danger here is that we are effectively using the dialog package to 
model states of the *user interface*. Thats a dangerous game and a 
slippery slope. The last thing I want to do is get into a mode where, in 
order to deploy a new service, I need to add states to the dialog event 
package to represent some new state in the UI that was added to support 
the feature.... this is one of the problems with the IN model, IMHO.

Indeed, this would lead me to conclude that the local ringback to alert 
the user to pick up is actually a LOCAL feature on the phone; if the 
user hangs up, and a BYE is sent, and a response code is received which 
indicates that the call is NOT terminated, the device itself would 
generate local rings to indicate to the user that they need to pick up 
as the call still exists. Such ringback would persist until the operator 
disconnects the call by sending a BYE. My argument here, and this 
argument is key - is that **this ringback is needed because of the 
physical nature of the UI, and the UI should not be of concern to the 
emergency service center**.

In the case of a PC application, if a user clicked "hangup" and received 
this error response code, it would tell the user about the problem and 
not terminate the call. In this case, the UI is different, and the 
"ringback" is not necessary to alert the user of the problem.

-Jonathan R.

Xuewen Li wrote:

> supported in SIP?  I realize that the wording may not be fully inline 
> with the SIP model, but this is a real issue to address.
> 
>  
> 
> Note that some of the terms below are in quotes since they are TDM 
> telephony terms but are used in this context to represent logical 
> equivalent. For example, "offhook" represents the action to initiate a 
> call and "onhook" represents the action to end the call.
> 
>  
> 
> Orig-hold refers to the ability to keep the call even when the 
> originator goes "onhook" before the operator releases the call. The 911 
> operator is notified of such event (i.e., the caller has gone "onhook") 
> so that the operator can initiate ringback (a special physical ringing 
> is applied.) When the caller goes "offhook", no "dial tone" is provided. 
> Rather the caller is reconnected to the original call to the 911 operator.  
> 
>  
> 
> CMSS has a DCS-OSPS header (tag value = RING) which provides the 
> mechanism for UA_b to request the "physical ringback".  However the 
> following pieces are missing.
> 
> 2.    Some mechanism to allow UA_b to request UA_a to apply orig-hold 
> for this call.
> 
> 3.    Some mechanism for UA_b to subscribe to UA_a's "onhook" or 
> "offhook" state changes.  One can argue whether or not these are session 
> states...
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 16 Feb 2004 22:38:17 -0500

I agree with Jonathan that end system intelligence is the answer here. 
After all, end systems have an interest in making emergency services work.

The -sos- draft (the version -01 that was refused since the -00 version 
was submitted just before the deadline...) defines the 'service' media 
feature tag for that, which includes plain 'sos' and the various 
sub-services (sos.fire, etc.). However, this is only necessary if the 
caller didn't know already that this was an emergency call. By the 
mechanism defined in the -sos- draft, it should, in almost all cases 
know this and thus be able to adjust UI behavior accordingly.

A simple 403 (Forbidden), in conjunction with the callee capabilities 
tag, should be sufficient as response to a premature BYE.

The problem with the approach of having the callee identify itself as a 
emergency call center and thereby modify caller behavior is that lends 
itself to pranks. Call my number and you can't hang up the phone until I 
let you. Telemarketers will love that feature :-)

(If the calling UA knows it's an emergency call, there is no need for 
the feature tag indication to control services.)

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Feb 2004 01:58:02 -0500

> tag, should be sufficient as response to a premature BYE.

I really think you will want a new response code here. My concern is 
that an application will effectively ignore the 403 and terminate the 
call anyway. I'd rather have a very explicit response code, so that its 
clear that the call cannot be terminated because its an emergency call.

> let you. Telemarketers will love that feature :-)

This seems like an S/MIME application that might actually even be 
deployable.

In principal, I would think that someone (NENA??) could hand out certs 
that do, in fact, certify that a user is an operator in an emergency 
service center. If a call I make completes to an user that has a cert 
declaring them as an emergency operation, my UA wouldn't allow me to 
terminate the call.

> the feature tag indication to control services.)

True. However, I can imagine cases where the call doesnt start as an 
emergency call, but turns into one. For example, what if I use some kind 
of call routing app where the destination number can be entered via 
stimulus (i.e., prepaid calling?). Maybe this is unsolvable, but the 
case does exist.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Feb 2004 09:55:12 -0500

> declaring them as an emergency operation, my UA wouldn't allow me to 

We've talked about this in the various emergency calling discussions and 
nobody who knows anything about the current 911 system, which is highly 
localized and decentralized, had any hope that this can work in the 
foreseeable future. We won't even talk about the difficulties of making 
this work internationally.

This gets more complicated in practice since you have the various 
'telematics' providers such as OnStar.

This is even more difficult than asserting an identity; Jon's 
trait-based auth draft, if I read it right, essentially says that trait 
(or role-based) authentication is only going to work in either a single 
administration or a federated one. The 911 system in the US is the 
opposite of both :-)

I've suggested to various NENA folks that they should look into this as 
a long-term goal, as it would simplify other things, but given that the 
solution is already specified for the callee caps case (in sos-01), 
there's probably not much you can do.

The 'cannot hang up during emergency calls' is mostly a canard - many 
existing analog systems don't have that property and nobody has been 
able to find a rule that says that this is a required feature. Given the 
many other ways you can lose contact with the ECC/PSAP, it is unclear 
that this adds much value in practice. The emergency-arch draft (like 
most existing systems) does specify call-back capability, which seems 
more useful and practical.

> stimulus (i.e., prepaid calling?). Maybe this is unsolvable, but the 

I'm not disagreeing with the desirability of indicating that somebody 
answering is an emergency call taker. I'm concerned that we simply do 
"and then magic happens and everybody agrees on a CA for emergency 
calls" since the problem is then somebody else's.

Henning