Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id

From: Christer Holmberg <[email-masked]>
Date: Thu, 24 Nov 2011 11:54:18 +0100

Hi Paul,

My take from the ECRIT session was that we don't want to move forward with the gruu approach, but rather use something else (e.g. a new RPH value), so I don't know how much time we should spend on discussing the gruu.

But, I'll try address also the gruu related questions anyway :)

-----------------

> After the meeting this morning I read the document. Here are a bunch of comments to start some discussion.
>
> Section 4:
>
>    - An eGRUU MUST be constructed following the same principles and
>    rules that apply for constructing a public GRUU.
>
> Section 6.2
>
>    If the Call-ID changes in a register refresh, the server will
>    invalidate all eGRUUs associated with that UA instance; the only
>   valid one will be the new one returned in that REGISTER response.
>
> This language is analogous to that for temp gruus, not permanent gruus.
> Yet the stated intent is that the egruu be like a public gruu.

The text used to say that an eGRUU is constructed following the same principles and rules that apply for constructioning a temporary GRUU, so I guess that text is something that by misstake was left unchanged.

------------------------------------

> Section 6.4:
>
>    A UA MUST NOT construct a self-made eGRUU.
>
> There may be a reason for this in IMS, but I see no general reason for this.
>
> A UA that assigns a gruu for itself to use in emergency calls can then
> recognize emergency callbacks and process them in a special way.

Yes, the UA can do that, but network entities may not be able to.

------------------------------------

> The requirement for a registrar assigned egruu seems to be predicated
> on emergency services provided by the registrar, or proxies and
> application servers in the routing path from the home proxy. The
> presence of such things, and how they work, is environment dependent.

Yes. The idea is not to specify WHAT the networks do, simply to be able to identify callback calls, IF they need to do something.

------------------------------------

> Section 6.6
>
>    NOTE: If the Contact header field of an initial SIP INVITE request
>    for an emergency call did not contain a "psabcb" parameter, a UA,
>    representing a PSAP, can insert the "psapcb" parameter in the
>    Request-URI of the initial SIP INVITE request for an PSAP callback
>    call.
>
> This is dubious. Modifying a URI you received is in general a bad idea.

That was indicated as an open issue in my presentation.

------------------------------------

>    If a UA does not represent a PSAP, making a PSAP callback call, it
>    MUST NOT insert an eGRUU and a "psapcb" parameter in the Request-URI
>    of the intial SIP INVITE request for the call.
>
> This makes little sense, and its not enforceable because UAs that
> don't implement this spec need not comply with it. In general, a UA
> that wants to send an out of dialog request to some UA it has a dialog
> with will simply use the remote Contact URI.

True.

I guess the key is that a UA that does understand the spec must not insert the parameter in the Contact header field for any other calls than emergency calls.

------------------------------------

> Then finally, I can find *no* explanation of what happens differently
> for a request containing the psapcb parameter, vs. one that does not.
> This is apparently very important, but totally opaque.
>
> Also, when the callback is generated with the egruu and its psapcb
> parameter, the UA does not get the parameter, except possibly via H-I.
> So its difficult for it to give special treatment for the callback call.
> Is there an assumption that it will use H-I for this?

That is something that was brought up at some point.

So, if there is a need for entities beyond the registrar (that will re-write the
R-URI, and hence remove the "psapcb" parameter) to be informed about the callback call,
we would either need H-I, or something else.

------------------------------------

> I also reviewed draft-ietf-ecrit-psap-callback-03 and didn't find any
> further enlightenment over this.
>
> ISTM that there are several requirements:
>
> - the callback should be addressed to the UA that initiated the
> emergency call, not to the AOR of that UA. Existing GRUU technology
> (either permanent, temporary, or self assigned satisfy this.)

Correct.

------------------------------------

> - the signaling network that routes the callback should avoid special
> treatments to callback calls that prevent the callback from reaching the
> intended UA. This requires that it be possible to identify callback calls.

I think the text is a little missleading, when it talks about AVOID special treatment.
The idea is that a call that is identified as a callback call CAN be given special treatment.

Also, it is not only about preventing the UA from not getting the call (which could happen e.g. in call forwarding cases), but in general not to apply services to callback calls (such as possibility to put the call on hold)

So, something like:

"should avoid applying services to the callback call, which in some cases might prevent the call from reaching the UA"

------------------------------------

> - the UA should give special priority to callback calls. For instance,
> drop other calls in order to take this one. This requires that it be
> possible to identify callback calls.

Correct.

------------------------------------

> - callback calls should be restricted to a limited set of callers, and
> no others. The allowed set is not well defined, but includes the
> recipient of the precipitating emergency call, plus some "friends". The
> reason for this is to prevent others from getting the special treatment.
> Defining this set is hard. Enforcing this limitation is also hard.

I'm not sure about the background to this requirement, so I'll let others comment.

The 3GPP requirement is that only the one who made the emergency call will get the callback call.

Of course, a PSAP can also call other users, but those calls are not seen or treated as callback calls.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 26 Nov 2011 15:00:44 +0100

Hi,

Another question that came up was which WG should be doing the protocol work.

Assuming we would simply define a new RPH namespace for PSAP callback calls, my understanding is that we could do that in ECRIT.

Right?

Regards,

Christer

________________________________________
From: Paul Kyzivat [[email-masked]]
Sent: Thursday, November 24, 2011 10:56 PM
To: Christer Holmberg
Cc: ECRIT
Subject: Re: [Ecrit] draft-holmberg-ecrit-emergency-callback-id

On 11/24/11 6:54 PM, Christer Holmberg wrote:
> Hi Paul,
> My take from the ECRIT session was that we don't want to move forward
> with the gruu approach, but rather use something else (e.g. a new RPH
> value), so I don't know how much time we should spend on discussing the
> gruu.

I'm happy with that direction.

        Thanks,
        Paul

> The text used to say that an eGRUU is constructed following the same
> principles and rules that apply for constructioning a temporary GRUU, so
> I guess that text is something that by misstake was left unchanged.
> Yes. The idea is not to specify WHAT the networks do, simply to be able
> to identify callback calls, IF they need to do something.
> I guess the key is that a UA that does understand the spec must not
> insert the parameter in the Contact header field for any other calls
> than emergency calls.
> Also, it is not only about preventing the UA from not getting the call
> (which could happen e.g. in call forwarding cases), but in general not
> to apply services to callback calls (such as possibility to put the call
> on hold)
> So, something like:
> "should avoid applying services to the callback call, which in some
> cases might prevent the call from reaching the UA"

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Sat, 26 Nov 2011 16:22:59 +0200

Hi Christer, 

I would do the work in ECRIT of course with reviews from the folks in
other RAI groups. My argument is that the motivation of the work comes
from ECRIT. 

The work on SIP Location Conveyance illustrated that problems show up
when you move the work away from the group where the requirements and
usage scenario come from.

Ciao
Hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Christer Holmberg
> Sent: Saturday, November 26, 2011 4:01 PM
> To: [email-masked]
> Cc: [email-masked]
> Another question that came up was which WG should be doing the
protocol
> work.
> 
> Assuming we would simply define a new RPH namespace for PSAP callback
> calls, my understanding is that we could do that in ECRIT.
> 
> Right?
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> >  > After the meeting this morning I read the document. Here are a
> bunch
> > of comments to start some discussion.
> >  >
> >  > Section 4:
> >  >
> > principles and rules that apply for constructioning a temporary
GRUU,
> so
> >  > There may be a reason for this in IMS, but I see no general
reason
> > for this.
> >  > So its difficult for it to give special treatment for the
callback
> > R-URI, and hence remove the "psapcb" parameter) to be informed about
> the
> > callback call,
> >  > intended UA. This requires that it be possible to identify
> callback
> > calls.
> >  > - callback calls should be restricted to a limited set of
callers,
> and
> >  > recipient of the precipitating emergency call, plus some
"friends".
> The
> > The 3GPP requirement is that only the one who made the emergency
call
> > will get the callback call.
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ecrit

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 28 Nov 2011 13:12:49 -0600

>usage scenario come from.

Location Conveyance started in 2003 in SIPPING (at the Vienna IETF), 
was moved to SIP, then back to SIPPING, then back to SIP, then on to 
SIPCORE. It was NEVER part of Geopriv, so that wasn't the problem. 
IMO the problems stemmed more from those insisting on requirements be 
met that didn't understand the construction of SIP than anything 
else, as SIP Location Conveyance was mostly transporting an already 
defined PIDF-LO (RFC 4119) or a URI (an ID that is in AD review now). 
The remainder of the issues all had to do with how what affected SIP 
(i.e., the header and header values that were mostly transparent to 
SIP within a SIP transaction).

For example, inserting a header value that changed the routing of the 
SIP request by a proxy, most often causing confusion by location 
recipients (because the proxy doesn't remove the existing location 
inserted by the UAC - hence there are now at least two locations in 
the same SIP request with zero guidance which is better or more authoritative).

I thank Jon for presenting how bad an idea that was (as well as 
several other bad ideas that were requirements placed on the editor - 
i.e., me), resulting in the great reduction in text as we cut out 
most of that cruft (and halved the size of the doc).

Bottom line, stating Location Conveyance as an example here was a poor choice.

James