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

From: [email-masked]
Date: Tue, 17 Feb 2004 11:31:13 EST

In a message dated 2/16/2004 10:42:05 PM Eastern Standard Time, 
[email-masked] writes:

> I agree with Jonathan that end system intelligence is the answer here. 
> After all, end systems have an interest in making emergency services work.
> 
> <snip>
> 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.)
> 

I agree, if one is only considering the requirement for calls to an emergency 
center. It would be better if the operation (holding of the call until the 
callee says to release it) occurs without instructions coming back from the 
callee. In the case of the call to an energency center, I believe the desire is 
that this same operation will occur if someone calls 911 and hangs up before the 
call even gets to the emergency center. In today's network, the originating 
side equipment (central office) can know to do this when someone dials an 
emergency number. For the SIP case, if the originating device can do this 
(recognize the emergency number) or an outbound proxy does it, fine.

But, looking at another part of the issue: When the emergency center gets a 
call, it should be able to assume that the operation will comply with this 
requirement and it has control of releasing the call. Of course, the problem with 
SIP (as with any evolving protocol) is that older devices would not support 
this capability, so I suppose we need to add a function so the originating 
device can tell the emergency center that it can do with (called party control of 
release). Perhaps the existance of the SOS URI could imply this.

Another part of the issue regards the "ringback" function, which allows the 
emergency center to re-ring the phone of someone who has gone "on-hook" (or 
whatever similar function is used on the SIP phone to indicate end-of-call). One 
of the earlier e-mails suggested that, if the phone recognized 911, it could 
immediately re-ring the phone if the person "hangs-up". I don't believe this 
meets the requirement. The re-ring needs to be under the control of the 
emergency center, so they can decide whether a re-ring is necessary or not.

Also, someone needs to look into the possible requirement to allow the 
emergency center to alert the user even while they are "off-hook" while the 
connection is being held. The American National Standard (for ISDN) included this 
function.

Also, note that the subject of these e-mails includes mention of "operator". 
The function of hold/ringback may not just be limited to calls to emergency.

There is another use of the holding function in today's network: tracing of 
malicious calls. In this case, the request to hold the call must come from the 
called end (but not the called party). I guess one of the things about SIP and 
the environment it is used in is that it should not be neccessary to hold a 
"connection" in order to provide malicious call trace. However, we need to 
consider what happens for various packet/Circuit switched interworking cases.

What this points out is the need to agree on the functional requirements for 
Support for Hold and Ringback before doing detailed protocol work.

Mike Pierce
Artel

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 17 Feb 2004 18:27:57 -0500

> someone calls 911 and hangs up before the call even gets to the 
> emergency center. In today's network, the originating side equipment 
> (central office) can know to do this when someone dials an emergency 
> number. For the SIP case, if the originating device can do this 

Repeating my earlier comments: even in today's modern networks (E911, 
ISUP, etc.), the callee-control is neither mandated nor universally 
supported. At least, I'm still waiting for a spec that says so. That 
said, the whole process of recognizing digits and sending 'sos' is also 
meant to trigger whatever caller-side behavior is appropriate.

> Another part of the issue regards the "ringback" function, which allows 
> the emergency center to re-ring the phone of someone who has gone 
> "on-hook" (or whatever similar function is used on the SIP phone to 
> indicate end-of-call). One of the earlier e-mails suggested that, if the 
> phone recognized 911, it could immediately re-ring the phone if the 
> person "hangs-up". I don't believe this meets the requirement. The 
> re-ring needs to be under the control of the emergency center, so they 
> can decide whether a re-ring is necessary or not.

Callback is described in emergency-arc.

> emergency center to alert the user even while they are "off-hook" while 
> the connection is being held. The American National Standard (for ISDN) 
> included this function.

Can you cite chapter and verse?

> There is another use of the holding function in today's network: tracing 
> of malicious calls. In this case, the request to hold the call must come 
> from the called end (but not the called party). I guess one of the 
> things about SIP and the environment it is used in is that it should not 
> be neccessary to hold a "connection" in order to provide malicious call 
> trace. However, we need to consider what happens for various 
> packet/Circuit switched interworking cases.

I'm sure a malicious caller will faithfully follow all SIP standards :-)

> 
> What this points out is the need to agree on the functional requirements 
> for Support for Hold and Ringback before doing detailed protocol work.
> 
> Mike Pierce
> Artel
> 

_______________________________________________
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