Subject: Re: [Ecrit] PSAP Call Backs

From: "Gunnar Hellstrom" <[email-masked]>
Date: Thu, 1 Jan 2009 23:26:39 +0100

Hi,

I get a bit nervous when I read SP-36, and compare it with what is desired
for users of relay services.

USA has just put regulations and technology in place for calling via relay
services to emergency services. The number that accompanies the call is
intended to be usable for call-back. The call-back MUST be taken through a
relay service, because the user need to use sign language or real-time text.

In Sweden, we have made plans and brief trials for a system with similar
goals as the one in USA, and Europe is on the same way.

The relay service is invoked in a call to the end user's number by a routing
evaluation that takes the call through a service instead of directly to the
user. It is done in one way in USA, but there are other optional ways to do
the same thing that seem to collide with the wording of som of the
requirements here.

The current wording of SP-36 can give the impression that that kind of
routing would not be allowed for the call-back.

"SP-36 Call backs to the Contact: header URI recieved within 30
   minutes of an emergency call must reach the device regardless of call
   features or services that would normally cause the call to be routed
   to some other entity."

I see similar risks in interpretation of this requirement, where I have
picked out the dangerous requirements:

"13.  Disabling of features

   ED-70/SP-39 User Agents and proxies MUST disable outgoing call
   features such as
--
   o  Call Transfer
   o  Three Way Call
--
   when an emergency call is established.  Also see ED-77 in Section 14.

   ED-71/SP-40 The emergency dial strings SHOULD NOT be permitted in
   Call Forward numbers or speed dial lists.

   ED-72/SP-41 The User Agent and Proxies SHOULD disable the following
   incoming call features on call backs from the PSAP:
--  
   o  Call Forward (all kinds)"
--

These operations may be essential for bringing in relay services and other
kind of supporting services in the call. I have raised this question before
and got an answer that was meant to take my fears away, referring to that
this has always been so in PSTN. I am still afraid that we make a lot of
good supporting actions impossible by these statements and would like to see
them deleted.

Regarding SP-36, I suggest rewording to:

"SP-36 Call backs to the Contact: header URI recieved within 30
   minutes of an emergency call must include call
   features or services that would normally be included in calls routed
   to the device."
 ----
And 39 - 40 - 41 to:

SP-39 User Agents and proxies MUST disable outgoing call features
   such as
   o  Call Waiting
   o  Flash hold
   o  Outbound Call Blocking
   when an emergency call is established.  Also see ED-77 in Section 14.

SP-41 The User Agent and Proxies SHOULD disable the following
   incoming call features on call backs from the PSAP:
   o  Call Waiting
   o  Do Not Disturb

I understand that there is a conflict between some traditions in this area,
and the new need for invoking supporting services, and look forward to a
discussion on what we lose and gain by the changes I propose.

Gunnar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tschofenig, Hannes (NSN - FI/Espoo)
Sent: Wednesday, December 31, 2008 11:21 AM
To: ECRIT
Subject: [Ecrit] PSAP Call Backs

Hi all, 

In the last few months we have seen increased interest in the topic of PSAP
call backs. 

Section 10 of  http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06
says:

   SP-36 Call backs to the Contact: header URI recieved within 30
   minutes of an emergency call must reach the device regardless of call
   features or services that would normally cause the call to be routed
   to some other entity.

More importantly, Section 13 says: 

   ED-73 Call backs SHOULD be determined by retaining the domain of the
   PSAP which answers an outgoing emergency call and instantiating a
   timer which starts when the call is terminated.  If a call is
   received from the same domain and within the timer period, sent to
   the Contact: or AoR used in the emergency call, it should be assumed
   to be a call back.  The suggested timer period is 5 minutes.

http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt proposed
another solution based on marking the callback using the "sos" URI
parameter. 

http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergency-rph-name
space/ proposes another solution by utilizing the Resource Priority Header. 

So, here are my high-level questions: 

A) Do you think that you understand the requirements that lead to a need for
a technical solution? 

B) Do you believe that more work beyond the mechanism described in Phone BCP
is needed? 

Ciao
Hannes
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

__________ NOD32 3724 (20081230) Information __________

Detta meddelande dr genomsvkt av NOD32 Antivirus.
http://www.nod32.com

_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 02 Jan 2009 14:15:15 -0600

At 04:21 AM 12/31/2008, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>Hi all,
>
>In the last few months we have seen increased interest in the topic of
>PSAP call backs.
>

within the namespace ID, the total thought (for PSAP callback) is here:

    This namespace will also be used
   for communications between emergency authorities, and MAY be used
   for emergency authorities calling public citizens. An example of
   the later is a PSAP operator calling back someone who previously
   called 9111/112/999 and the communication was terminated before it
   should have been (in the operator's judgment).

Notice this is all based on the MAY in the first sentence, therefore 
it can be considered an afterthought, i.e., something that can be 
utilized/specified later.

the "sos" parameter solution is more definitive, yet it should 
identify a priority marking (in SIP), given that there is already a 
defined way to do that in SIP, and a second way shouldn't be defined 
- as it will only lead to interoperability issues.

>A) Do you think that you understand the requirements that lead to a need
>for a technical solution?
>
>B) Do you believe that more work beyond the mechanism described in Phone
>BCP is needed?
>
>Ciao
>Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 3 Jan 2009 09:15:01 -0500

Couple of thoughts here:

In the past several months, I have been involved with a couple of instances
where call backs turned out to be very difficult because they are not marked
(in the PSTN).  Gunnar cited one:

A relay provider handles an emergency call.  The PSAP calls the deaf caller
back.  Relay providers often have a queue of calls waiting for an available
interpreter.  US regulation now (as of last week) says emergency calls and
call backs should get priority on the queue.  How does the relay provider
know that an incoming call is a call back?

Another one is a telephony service with incoming call restrictions.  An
example is a phone for a child where the parent controls who can call the
child.  The child makes an emergency call.  A callback is needed.  The call
restrictions would bar the call unless it was known that it was an emergency
call.

Besides marking, there needs to be some other phonebcp-like text.  For
example, a callback should not normally be diverted (call forwarding).  T
may (needs some discussion) need to get through if do not disturb is enabled
(for example, inadvertently).

As with incoming calls, some minimum standards are needed on the signaling.

I also want to point out that resource priority marking is NOT a good choice
for an overall callback mark, the same way that the Route header sos urn is
not a good choice for a resource priority mark.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James M. Polk
Sent: Friday, January 02, 2009 3:15 PM
To: Tschofenig, Hannes (NSN - FI/Espoo); ECRIT
Subject: Re: [Ecrit] PSAP Call Backs

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Sat, 3 Jan 2009 20:28:41 +0200

There are two different aspects: 

A) A decision that decides whether a call back has to be marked or not

B) When the decision is made that is has to be marked then how the marking
is going to look like. 

Regarding (A): This might be a policy issues. Some PSAPs might want to use
this indication and others might not. Nothing we have to worry about. 

Regarding (B): Here there needs to be one way todo the marking -- not
multiple ways. It would just increase the implementation complexity, the
number of error cases and interop problems. 

I am not sure to what your "MAY" statement refers to -- to (A) or (B). 

Ciao
Hannes

>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of James M. Polk
>Sent: 02 January, 2009 22:15
>>http://tools.ietf.org/id/draft-patel-ecrit-sos-parameter-01.txt 
>>proposed another solution based on marking the callback using 
>the "sos" 
>>URI parameter.
>>
>>http://tools.ietf.org/wg/ecrit/draft-ietf-ecrit-local-emergenc
>y-rph-nam
>>e space/ proposes another solution by utilizing the Resource Priority 
>>Header.
>
>Notice this is all based on the MAY in the first sentence, 
>therefore it can be considered an afterthought, i.e., 
>something that can be utilized/specified later.
>
>identify a priority marking (in SIP), given that there is 
>already a defined way to do that in SIP, and a second way 
>shouldn't be defined
>>A) Do you think that you understand the requirements that lead to a 
>>need for a technical solution?
>>
>>B) Do you believe that more work beyond the mechanism described in 
>>Phone BCP is needed?
>>
>>Ciao
>>Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 04 Jan 2009 16:25:32 -0600

At 08:15 AM 1/3/2009, Brian Rosen wrote:
>for an overall callback mark,

I'd like to second this view, and offer that callback marking text be 
removed from
draft-ietf-ecrit-local-emergency-rph-namespace.

Comments?

James

>the same way that the Route header sos urn is

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 04 Jan 2009 16:39:30 -0600

>I am not sure to what your "MAY" statement refers to -- to (A) or (B).

MAY means not prohibited, and can be specified in a future doc.

Regarding your questions A and B, I'm not a fan of using an RP 
namespace to do callbacks, given that I don't believe we can be sure 
or the signaling path in the reverse direction (i.e., from the PSAP 
back to the original UAC caller), so I'm not sure how we can believe 
any marking indication is going to work even  50% of the time (if that).

Remember, you personally don't trust the UAC to set a correct esnet 
namespace, so how can you trust the UAC to correctly receive this 
same esnet namespace and do the right things about that SIP INVITE?

I believe the same applies to the sos-parameter draft. How do we know 
it'll be only used during emergency callback, and not used to prevent 
call forwarding or otherwise disable features the UA endpoint 
normally wants applied to any inbound call attempt?

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 5 Jan 2009 10:47:19 -0500

I would have said that we decide if callbacks should have special treatment
of any kind.

If we decide that they should, then we decide how we will mark them, and
then what the behavior is for that marking.

Please do not confuse the resource priority marking and behavior with this
discussion.  As with the emergency call marking (urn:service:sos in Route),
and the associated behaviors in PhoneBCP, the RPH is an independent marking
and behavior specification.  If we mark call backs, it won't be with RPH.  A
callback MAY also have an RPH marking, and there could be behavior
associated with that with respect to priority handling within a network.
Similarly, the packets of a callback could have a DiffServ marking, and
behavior associates with that marking within a network.

I think we should have a call back marking, and we should specify behaviors
for that marking.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Saturday, January 03, 2009 1:29 PM
To: 'James M. Polk'; Tschofenig, Hannes (NSN - FI/Espoo); 'ECRIT'
Subject: Re: [Ecrit] PSAP Call Backs

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Jan 2009 11:00:07 -0600

>behavior associates with that marking within a network.

I (again) agree with all of the above (which has been said over and 
over again).

>I think we should have a call back marking, and we should specify behaviors

I'm on the fence about callback marking, mostly because I believe 
there is an unpredictable path back to the original UAC, and even if 
marked, do we know the receiving proxies or UAC will have any 
awareness of this marking?  If not, why have this discussion and 
complexity attempting to elicit a marking and associated behavior 
that falls on deaf ears?

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 5 Jan 2009 20:07:51 +0100

I think I agree with what Brian is saying here, but I would turn the statement round.

We should decide what special behaviours callback calls required, and then identify the appropriate means of signalling to generate that behaviour.

That means if we identify that callback calls need special treatment in the network, then RPH may be the way to do it. If we want to override incoming call bahaviour in the destination UA, then we find an appropriate way of doing that (along with a security solution to prevent misuse.

I though we had decided to deal with callback issues with a separate requirements draft. As such I would support taking out callback text from all documents at the moment, not with the idea that that might not be the solution, but that we come up with a complete package of solutions in the future.

regards

Keith  

> On Behalf Of Brian Rosen
> Sent: Monday, January 05, 2009 3:47 PM
> To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes 
> (NSN - FI/Espoo)'; 'ECRIT'
> I would have said that we decide if callbacks should have 
> special treatment of any kind.
> 
> If we decide that they should, then we decide how we will 
> mark them, and then what the behavior is for that marking.
> 
> Please do not confuse the resource priority marking and 
> behavior with this discussion.  As with the emergency call 
> marking (urn:service:sos in Route), and the associated 
> behaviors in PhoneBCP, the RPH is an independent marking and 
> behavior specification.  If we mark call backs, it won't be 
> with RPH.  A callback MAY also have an RPH marking, and there 
> could be behavior associated with that with respect to 
> priority handling within a network.
> Similarly, the packets of a callback could have a DiffServ 
> marking, and behavior associates with that marking within a network.
> 
> I think we should have a call back marking, and we should 
> specify behaviors for that marking.
> 
> Brian
> 
> On Behalf Of Hannes Tschofenig
> B) When the decision is made that is has to be marked then 
> how the marking is going to look like. 
> 
> Regarding (A): This might be a policy issues. Some PSAPs 
> might want to use this indication and others might not. 
> Nothing we have to worry about. 
> 
> Regarding (B): Here there needs to be one way todo the 
> marking -- not multiple ways. It would just increase the 
> implementation complexity, the number of error cases and 
> interop problems. 
> 
> >>Section 10 of  
> http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-06
> >>says:
> >>
> therefore it 
> >can be considered an afterthought, i.e., something that can be 
> >the "sos" parameter solution is more definitive, yet it 
> should identify 
> >a priority marking (in SIP), given that there is already a 
> defined way 
> >to do that in SIP, and a second way shouldn't be defined

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Jan 2009 13:20:15 -0600

At 01:07 PM 1/5/2009, DRAGE, Keith (Keith) wrote:
>We should decide what special behaviours callback calls required, 
>and then identify the appropriate means of signalling to generate 
>that behaviour.
>
>That means if we identify that callback calls need special treatment 
>in the network, then RPH may be the way to do it. If we want to 
>override incoming call bahaviour in the destination UA, then we find 
>an appropriate way of doing that (along with a security solution to 
>prevent misuse.
>
>I though we had decided to deal with callback issues with a separate 
>requirements draft. As such I would support taking out callback text 
>from all documents at the moment, not with the idea that that might 
>not be the solution, but that we come up with a complete package of 
>solutions in the future.

I think this is appropriate

---

From: "Milan Patel" <[email-masked]>
Date: Tue, 6 Jan 2009 13:46:04 -0000

Keith's suggestions sound sensible to me.
Regards,
Milan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of James M. Polk
Sent: 05 January 2009 19:20
To: DRAGE, Keith (Keith); Brian Rosen; 'Hannes Tschofenig'; 'Tschofenig,
Hannes (NSN - FI/Espoo)'; 'ECRIT'
Subject: Re: [Ecrit] PSAP Call Backs

At 01:07 PM 1/5/2009, DRAGE, Keith (Keith) wrote:
>We should decide what special behaviours callback calls required, and 
>then identify the appropriate means of signalling to generate that 
>behaviour.
>
>That means if we identify that callback calls need special treatment in

>the network, then RPH may be the way to do it. If we want to override 
>incoming call bahaviour in the destination UA, then we find an 
>appropriate way of doing that (along with a security solution to 
>prevent misuse.
>
>from all documents at the moment, not with the idea that that might not

>be the solution, but that we come up with a complete package of 
>solutions in the future.

> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Brian Rosen
> > To: 'Hannes Tschofenig'; 'James M. Polk'; 'Tschofenig, Hannes (NSN -

> > FI/Espoo)'; 'ECRIT'
> > I would have said that we decide if callbacks should have special 
> > treatment of any kind.
> >
> > If we decide that they should, then we decide how we will mark them,

> > and then what the behavior is for that marking.
> >
> > Please do not confuse the resource priority marking and behavior 
> > with this discussion.  As with the emergency call marking 
> > (urn:service:sos in Route), and the associated behaviors in 
> > PhoneBCP, the RPH is an independent marking and behavior 
> > specification.  If we mark call backs, it won't be with RPH.  A 
> > Similarly, the packets of a callback could have a DiffServ marking, 
> > and behavior associates with that marking within a network.
> >
> > I think we should have a call back marking, and we should specify 
> > behaviors for that marking.
> >
> > Brian
> >
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Hannes Tschofenig
> > B) When the decision is made that is has to be marked then how the 
> > marking is going to look like.
> >
> > Regarding (A): This might be a policy issues. Some PSAPs might want 
> > to use this indication and others might not.
> > Regarding (B): Here there needs to be one way todo the marking -- 
> > not multiple ways. It would just increase the implementation 
> > complexity, the number of error cases and interop problems.
> >
> > >>A) Do you think that you understand the requirements that lead to 
> > >>a need for a technical solution?
> > >>