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

From: Paul Kyzivat <[email-masked]>
Date: Wed, 16 Nov 2011 14:03:44 +0800

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.

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.

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.

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.

    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.

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?

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.)

- 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.

- 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.

- 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.

	Thanks,
	Paul