Subject: Re: [Ecrit] Callbacks and phonebcp

From: "Brian Rosen" <[email-masked]>
Date: Thu, 1 May 2008 09:42:08 -0400

I'm always ready and willing to supply an answer to questions like this.  We
all know there is no really right answer, but any answer is a good answer.

So, 15 minutes.  That's enough.  An hour would be better, but 15 minutes is
enough.  After that time, the AoR can be used.  Might not get back to the
same device.  That's okay. 

-phonebcp applies to end devices as well as proxies, so I think we're
covered there.

Brian

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
DRAGE, Keith (Keith)
Sent: Thursday, May 01, 2008 4:56 AM
To: Perry Prozeniuk; [email-masked]
Subject: Re: [Ecrit] Callbacks and phonebcp

There is no point in writing a MUST unless you tell us what the period of
time is. How can I assess the conformance without knowing that value. We
have certainly been round that loop in 3GPP and noone has been able to
specify how long after the initial call a callback must be possible.

Further this is a set of CPE requirements, and the CPE does not have
complete control over whether the Contact header remains valid.

regards

Keith

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Perry Prozeniuk
Sent: Wednesday, April 30, 2008 8:26 PM
To: [email-masked]
Subject: [Ecrit] Callbacks and phonebcp

As part of the NENA CPE IP Capable PSAP working group we have been looking
into the SIP callback information and how the PSAP will use this.

In phonebcp, following references are found:

==============

   3.   The From header MUST be present and SHOULD be the AoR of the

        caller.

.

   6.   A Contact header MUST be present which MUST be globally

        routable, for example a GRUU [I-D.ietf-sip-gruu], to permit an

        immediate call-back to the specific device which placed the

        emergency call.

And a little later:

   5.  Either a P-Asserted-Identity [RFC3325] or an Identity header

       [RFC4474], or both, MUST be included to identify the sender.

=============

Specifically in reference to (6) above, I believe that there is a potential
issue.  The statement that the contact header MUST be globally routable is
not sufficient.  It MUST also be usable for a period of time after the call
completes.  

If one looks at a situation where there is a Session Border Controller (SBC)
between the SIP phone and the PSAP, the SBC may replace the contact header
with a temporary address that although is globally routable is ONLY valid
for the duration of the call.  A GRUU would satisfy both of these
conditions, however so would any other globally routable SIP URI for the
originating phone that remained valid after the call completion.  A GRUU
would be preferred.

 I am suggesting the the wording be strengthened somewhat to ensure that the
Contact URI MUST be usable for callback for a short period of time after the
call completes (e.g. a few minutes) and the a GRUU SHOULD be specified.

Of course if the phone is disconnected, etc then the contact may not be
usable at all after the call and the other address fields (e.g. the AOR)
will need to be used for callback which may or may not reach the caller
directly.  In most cases the phone will remain operational following the
call completion and the contact information should allow the originating
phone to be reached directly.

Perry

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

---

From: "Perry Prozeniuk" <[email-masked]>
Date: Thu, 1 May 2008 13:01:50 -0400

I agree with Brian.  
 
The objective is to make sure that the network equipment is designed
such that the CONTACT information provided with an emergency call
remains valid after the call.  There are many factors that impact the
exact amount of time that it could/should remain valid.  The existing
wording does not require the network equipment to provide a mechanism
that extends the CONTACT beyond the end of the current call.
 
The objective for the amount of time is really an issue for PSAP
operations.  These are the people that are going to be making the
callbacks. I will send a question to the NENA operations group to obtain
their opinion on a objective the the amount of time the CONTACT remains
valid.  This should provide the minimum duration that would be
considered a best current practice.  As technology people we could
debate this forever since there isn't really a technical answer other
than it needs to remain valid for a while.
 
Perry

________________________________

From: Brian Rosen [mailto:[email-masked]] 
Sent: Thursday, May 01, 2008 9:42 AM
To: 'DRAGE, Keith (Keith)'; Prozeniuk, Perry (CAR:9T51); [email-masked]
Subject: RE: [Ecrit] Callbacks and phonebcp

I'm always ready and willing to supply an answer to questions like this.
We all know there is no really right answer, but any answer is a good
answer.

So, 15 minutes.  That's enough.  An hour would be better, but 15 minutes
is enough.  After that time, the AoR can be used.  Might not get back to
the same device.  That's okay. 

Brian

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of DRAGE, Keith (Keith)
Sent: Thursday, May 01, 2008 4:56 AM
To: Perry Prozeniuk; [email-masked]
Subject: Re: [Ecrit] Callbacks and phonebcp

There is no point in writing a MUST unless you tell us what the period
of time is. How can I assess the conformance without knowing that value.
We have certainly been round that loop in 3GPP and noone has been able
to specify how long after the initial call a callback must be possible.

regards

Keith

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Perry Prozeniuk
	Sent: Wednesday, April 30, 2008 8:26 PM
	To: [email-masked]
	Subject: [Ecrit] Callbacks and phonebcp

	As part of the NENA CPE IP Capable PSAP working group we have
been looking into the SIP callback information and how the PSAP will use
this.

	==============

	   3.   The From header MUST be present and SHOULD be the AoR of
the

	        caller.

	...

	        routable, for example a GRUU [I-D.ietf-sip-gruu], to
permit an

	        immediate call-back to the specific device which placed
the

	        emergency call.

	And a little later:

	   5.  Either a P-Asserted-Identity [RFC3325] or an Identity
header

	       [RFC4474], or both, MUST be included to identify the
sender.

	=============

	Specifically in reference to (6) above, I believe that there is
a potential issue.  The statement that the contact header MUST be
globally routable is not sufficient.  It MUST also be usable for a
period of time after the call completes.  

	If one looks at a situation where there is a Session Border
Controller (SBC) between the SIP phone and the PSAP, the SBC may replace
the contact header with a temporary address that although is globally
routable is ONLY valid for the duration of the call.  A GRUU would
satisfy both of these conditions, however so would any other globally
routable SIP URI for the originating phone that remained valid after the
call completion.  A GRUU would be preferred.

	 I am suggesting the the wording be strengthened somewhat to
ensure that the Contact URI MUST be usable for callback for a short
period of time after the call completes (e.g. a few minutes) and the a
GRUU SHOULD be specified.

	Of course if the phone is disconnected, etc then the contact may
not be usable at all after the call and the other address fields (e.g.
the AOR) will need to be used for callback which may or may not reach
the caller directly.  In most cases the phone will remain operational
following the call completion and the contact information should allow
the originating phone to be reached directly.

	Perry

---

From: "Winterbottom, James" <[email-masked]>
Date: Thu, 1 May 2008 17:37:37 -0500

Actually if you made it 30 minutes you would be inline with how long
many of the deployed GMLCs cache ESRK to call-back number mappings
before throwing them away.

Cheers

James

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Perry Prozeniuk
Sent: Friday, 2 May 2008 3:02 AM
To: Brian Rosen; DRAGE, Keith (Keith); [email-masked]
Subject: Re: [Ecrit] Callbacks and phonebcp

I agree with Brian.  

Perry

Brian

regards

Keith

	==============

	        caller.

	...

	        emergency call.

	And a little later:

	=============

	Perry

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 03 May 2008 20:48:53 +0300

Hi Perry,

interesting that you mention call-backs. I asked a question about 
call-backs at the last emergency services workshop to better 
differentiate the
* "nice-to-have" features, and the
* requirement from a regulatory point of view.

Here is what I understood: It is required from a regulator point of view 
to supply the PSAP with some mechanism to call you back. This would 
already be covered by the AoR.

There is, however, no regulatory requirement to
* have the call-back being marked as "emergency call"
* have the call-back being treated differently than any other normal 
call (including the ability to bypass authorization policies, etc.)

I am particularly pointing to this differentiation since we (including 
the 3GPP) add a lot of features along the way that are, strictly 
speaking, nice but not fundamentally necessary. As such, a number of the 
features we are discussing (like making callbacks from the PSAP to the 
end host) are more or less "nice-to-have" rather than anything else.

I understand your suggestion and I think it is useful to make sure that 
some "state" remains present for some amount of time, particularly with 
the desire to reach exactly the device where the call came from originally.

As such, I wonder whether the requirement for GRUU (as a "MUST") isn't 
even a bit strong in that case. It is nice to use GRUU, if available, 
but if it isn't then that is not a disaster either.

Feedback appreciated!

Ciao
Hannes

PS: The SIP Identity you mention loosely relates to callbacks as such. 
Providing the PSAP with identity information about the caller is 
important for several reasons.

Perry Prozeniuk wrote:
> As part of the NENA CPE IP Capable PSAP working group we have been 
> looking into the SIP callback information and how the PSAP will use this.
> …
> Specifically in reference to (6) above, I believe that there is a 
> potential issue. The statement that the contact header MUST be 
> If one looks at a situation where there is a Session Border Controller 
> (SBC) between the SIP phone and the PSAP, the SBC may replace the 
> contact header with a temporary address that although is globally 
> routable SIP URI for the originating phone that remained valid after 
> the call completion. A GRUU would be preferred.
> I am suggesting the the wording be strengthened somewhat to ensure 
> that the Contact URI MUST be usable for callback for a short period of 
> time after the call completes (e.g. a few minutes) and the a GRUU 
> SHOULD be specified.
> Of course if the phone is disconnected, etc then the contact may not 
> be usable at all after the call and the other address fields (e.g. the 
> AOR) will need to be used for callback which may or may not reach the 
> caller directly. In most cases the phone will remain operational 
> ------------------------------------------------------------------------
>

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 3 May 2008 15:32:06 -0400

The call back requirement is not a legal requirement, but it is a hard
requirement.  I believe, and I'll get NENA to express an opinion if you need
one, that given how IP devices work, an address that can be used to get back
to the device that placed the call, which may be different from the AoR, is
a requirement, not a nice to have.

In all other services, there really is only one device per TN (ignoring the
multiple devices on one number in a wireline environment).  The TN is a
sufficient address to get back to the device that placed the call if the
call is inadvertently dropped for some reason.  With IP services, we have a
very real possibility that we would NOT get back to the same device.

You can, if you want, make -phonebcp more complex by saying you don't have
to have Contact with a GRUU if AoR will reliably get you back to the same
device if called within the (15/30) minute window we have been discussing.
I'd rather leave it as it is.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hannes Tschofenig
Sent: Saturday, May 03, 2008 1:49 PM
To: Perry Prozeniuk
Cc: [email-masked]
Subject: Re: [Ecrit] Callbacks and phonebcp

Hi Perry,

Feedback appreciated!

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 03 May 2008 22:45:49 +0300

I am not saying it is not useful but there is clearly a slippery slope. 
The 3GPP emergency registration (unless I misunderstood it), the 
discussion dealing with authorization policies and other supplementary 
services, using emergency call marking for callbacks, etc. quickly turn 
a simple thing into something complex.

Do we (NENA, for example) actually have some statistical data about 
callbacks?

Ciao
Hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 3 May 2008 15:56:35 -0400

Yah, I hear you, but I think it's inevitable.

The emergency registration is a result of unauthenticated device support.

Supplementary service disabling, if that is what you are talking about, has
been implemented in wireline and wireless for a very long time

Call back marking is a new one.  I believe the issue comes from a variety of
new services which restrict who can call in to a device.  We're facing this
very problem now with new wireless services (parental control of who can
call their children for example).  

Brian

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, May 03, 2008 3:46 PM
To: Brian Rosen
Cc: 'Perry Prozeniuk'; [email-masked]
Subject: Re: [Ecrit] Callbacks and phonebcp

Ciao
Hannes

---

From: "Perry Prozeniuk" <[email-masked]>
Date: Tue, 6 May 2008 11:29:41 -0400

There are a number of issues, as you mention, around callbacks.  
 - If the caller's "address" can be used to reach the original
caller/device
 - If when it gets there, there are supplementary services that
interfere with the call
 - if there is a need for mark callbacks as "emergency" such that they
receive priority / different treatment.

My suggestions were focused on the first point and I think it would be a
"best practice" to ensure that the contact header contained an address
(e.g. a GRUU) that allowed the originating device to be reachable
following the call for a period of time (duration discussed earlier).

The interference of supplementary services is another issue.  The
network would need to be expecting a callback or be able to detect one
to bypass these services.  Currently some systems simply disable these
services for a period of time following an emergency call to allow for
possible callback (similar duration discussion as the address validity).
Another "best practice" would be to do just this in the absence of
callbacks being marked as "emergency".

Marking callbacks from PSAPS as "emergency" would enable priority
treatment of these calls in the network and specific behaviors on the
terminating user agents (call servers, phones, etc) that may impose
supplementary services to re-route the call.  It would  be a "best
practice" to disable/bypass these supplementary services when the call
is marked as "emergency".  Marking the calls as emergency and other
priority handling in the network is a separate issue.  This is a much
more complex issue since I'm sure we could discuss at length the desire
to allow the callback to be rerouted by these services in order to be
able to reach the caller (perhaps on a different device).

Callback's to "unauthorized" phones is another topic.

Perry

-----Original Message-----
From: Hannes Tschofenig [mailto:[email-masked]] 
Sent: Saturday, May 03, 2008 3:46 PM
To: Brian Rosen
Cc: Prozeniuk, Perry (CAR:9T51); [email-masked]
Subject: Re: [Ecrit] Callbacks and phonebcp

Ciao
Hannes

> requirement.  I believe, and I'll get NENA to express an opinion if 
> you need one, that given how IP devices work, an address that can be 
> used to get back to the device that placed the call, which may be 
> different from the AoR, is a requirement, not a nice to have.
>
> In all other services, there really is only one device per TN 
> (ignoring the multiple devices on one number in a wireline 
> environment).  The TN is a sufficient address to get back to the 
> device that placed the call if the call is inadvertently dropped for 
> some reason.  With IP services, we have a very real possibility that
we would NOT get back to the same device.
>
> You can, if you want, make -phonebcp more complex by saying you don't 
> have to have Contact with a GRUU if AoR will reliably get you back to 
> the same device if called within the (15/30) minute window we have
been discussing.

> Of Hannes Tschofenig
> Here is what I understood: It is required from a regulator point of 
> view to supply the PSAP with some mechanism to call you back. This 
> would already be covered by the AoR.
>

> speaking, nice but not fundamentally necessary. As such, a number of 
> the features we are discussing (like making callbacks from the PSAP to

> the end host) are more or less "nice-to-have" rather than anything
else.
>
> I understand your suggestion and I think it is useful to make sure 
> that some "state" remains present for some amount of time, 
> particularly with the desire to reach exactly the device where the
call came from originally.

>> 6. A Contact header MUST be present which MUST be globally routable, 
>> for example a GRUU [I-D.ietf-sip-gruu], to permit an immediate 
>> call-back to the specific device which placed the emergency call.
>> And a little later:
>> Controller

>> that the Contact URI MUST be usable for callback for a short period 
>> of time after the call completes (e.g. a few minutes) and the a GRUU 
>> SHOULD be specified.

>> following the call completion and the contact information should 
>> allow the originating phone to be reached directly.
>>
>> Perry