Subject: [Ecrit] What's up with draft-patel-ecrit-sos-parameter

From: Cullen Jennings <[email-masked]>
Date: Fri, 14 Nov 2008 18:51:50 -0700

I was hoping to see more discussion of this draft on the list. Do  
folks love it, hate it, think it's done, want to use something else,  
not understand the problem, whatever? Thoughts?

Cullen

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

---

From: "Milan Patel" <[email-masked]>
Date: Sat, 15 Nov 2008 13:43:20 -0000

Hi Cullen,

Thanks for encouraging further discussion on this draft. Currently, it
aligns with the proposed use of this URI parameter in 3GPP. During last
week's 3GPP meeting, further requests were made for folks to provide
their comments on the ECRIT mailing list. Keith will present the draft
on my behalf at IETF73.

Best regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Cullen Jennings
Sent: 15 November 2008 01:52
To: ECRIT
Subject: [Ecrit] What's up with draft-patel-ecrit-sos-parameter

I was hoping to see more discussion of this draft on the list. Do folks
love it, hate it, think it's done, want to use something else, not
understand the problem, whatever? Thoughts?

Cullen

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 15 Nov 2008 14:27:00 -0500

I have discussed this with Milan.  I agree that we need SOMETHING to mark an
emergency registration.  A parameter on a URI may be the best way to do
that, or something else may be appropriate.

In our discussion, I think I convinced him that the service URN can stay on
the call until it gets to the UAS, even if that was a gateway, and thus is a
sufficient marking for the call.

Again, I think I convinced Milan that having a URI parameter doesn't fix the
problem of a UAC that doesn't recognize a call as an emergency call.  If it
could recognize the parameter, it could follow phonebcp to determine what is
an emergency call, etc.

Call backs need a separately chartered item.  I don't think we're going to
end up with a URI parameter to mark a call back, but I won't prejudice what
comes out of that work.  Requirements first I would say.

Net net, 3GPP needs an emergency registration.  Other networks may have
similar needs.  We need a way to mark an emergency registration.  A
parameter is one way.  Is that the best way?  If it is, this work should go
ahead with that single purpose.  If not, this work should die, and something
else should take its place.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Milan Patel
Sent: Saturday, November 15, 2008 8:43 AM
To: Cullen Jennings; ECRIT
Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter

Hi Cullen,

Best regards,
Milan

-----Original Message-----

Cullen

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 15 Nov 2008 15:06:20 -0500

Does the emergency registration use the same authentication  
credentials as the regular registration? Besides being for call backs,  
what else is different?

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Sun, 16 Nov 2008 08:11:51 +0100

In IMS

-	Authentication is the same.

-	The emergency registration does not use the service route
extension.

-	The emergency registration does not create a temporary GRUU.

-	The emergency registraion cannot be deregistered by the user. 

regards

Keith 

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Henning Schulzrinne
> Sent: Saturday, November 15, 2008 8:06 PM
> To: Brian Rosen
> Cc: 'ECRIT'
> credentials as the regular registration? Besides being for 
> call backs, what else is different?
> 
> > Net net, 3GPP needs an emergency registration.  Other networks may 
> > have similar needs.  We need a way to mark an emergency 
> registration.  
> > A parameter is one way.  Is that the best way?  If it is, this work 
> > should go ahead with that single purpose.  If not, this work should 
> > die, and something else should take its place.
> >

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 16 Nov 2008 11:21:27 -0500

Is the registration request sent to the same registrar as the regular  
registration?

I don't quite understand how this differs from a UAC perspective. The  
registration doesn't really return any data to the UAC, and the  
registrar can already keep whatever information it wants, i.e., not de- 
register.

The draft is not too helpful here: "emergency registration is  
necessary to inform the registrar that the contact address and AOR  
being registered is to be used for emergency calls, and roaming and  
barring restrictions should not be applied for the registered AOR."

Why would a UA submit a different AOR and contact address for the  
emergency registration?

I think conflating the call marking [REQ2] with the registration  
marking [REQ1] just adds confusion to the discussion, as they seem to  
be orthogonal issues. It is not clear that the same solution is  
appropriate in all cases, so this seems to be a case of reverse- 
engineering the requirements from a solution.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Sun, 16 Nov 2008 10:29:21 -0800

>else should take its place.

I think the fastest way to move forward at this point is to charter this
document as a working group item.  That will get 3gpp on the
right track (and I believe that there are other tracks...).  Once there,
if we discover that the current method proposed needs adjustment,
we can do so.  But absent a working group draft and an agreement
to work on it, we're likely to see different parts of the system
go different ways. 

This seems like a reasonable document to start from, at least to me.

					Ted

---

From: "Milan Patel" <[email-masked]>
Date: Mon, 17 Nov 2008 13:11:18 -0000

Hi Henning

The registration request is sent to the same registrar as the regular
registration - all registration occurs with the home network. 

Registration allows the UAC to get a tel-URI for use in emergency calls.
This is required so that the emergency caller can be contacted (via call
back) in the case where the PSAP is located in the PSTN. Additionally,
during call-back, the Serving-CSCF has knowledge of the route towards
the emergency caller. If a particular AOR was registered, it is possible
to ensure that special handling is applied for this AOR - suppress
network based services and barring restrictions. In the Internet Draft,
I didn't want to go into all the requirements of registration since
these are covered in 3GPP TS 23.167 (which is a normative reference). 

3GPP requirements mandate that barred identities can be used to initiate
emergency calls. Roaming resitrctions on any identities registered
during emergency call initiation must be lifted so these identities can
be used when initiating an emergency call when roaming.  Registration at
the time of emergency call initiation allows these requirements to be
fulfilled. Emergency Registration, while roaming, forces the UE to
register via register via a local proxy so that a local Emergency-CSCF
can be reached. Existing registrations may have resulted in the UE
attached to a home proxy, thus a local E-CSCF cannot be reached.

Regards,
Milan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Henning Schulzrinne
Sent: 16 November 2008 16:21
To: DRAGE, Keith (Keith)
Cc: ECRIT
Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter

The draft is not too helpful here: "emergency registration is necessary
to inform the registrar that the contact address and AOR being
registered is to be used for emergency calls, and roaming and barring
restrictions should not be applied for the registered AOR."

I think conflating the call marking [REQ2] with the registration marking
[REQ1] just adds confusion to the discussion, as they seem to be
orthogonal issues. It is not clear that the same solution is appropriate
in all cases, so this seems to be a case of reverse- engineering the
requirements from a solution.

Henning

On Nov 16, 2008, at 2:11 AM, DRAGE, Keith (Keith) wrote:

>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Henning Schulzrinne
>> credentials as the regular registration? Besides being for call 
>> backs, what else is different?
>>

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Nov 2008 11:11:10 -0500

My general question is whether we need special mechanisms for  
REGISTER, as we have enough complexity already. (I won't go into the  
INVITE case for now, as that seems to be a more complicated issue and  
raises a significant number of fraud prevent issues unless there is no  
incentive for non-emergency parties to add a "sos".)

There seem to be two REGISTER cases:

- "Normal" user (not barred from roaming, lacking  
authentication, ...): As far as I can tell, the device doesn't do  
anything different and wouldn't know about including special Contact  
headers in any event. The draft doesn't really specify what happens in  
that case, as it seems to focus far too much on syntax and not on  
behavior. Your note seems to indicate that the registrar returns some  
kind of special (tel) URI that the UA should use as a contact in the  
call. The draft says "will be included in the Contact header" - but  
not by whom.

If we really want special Contact URIs that the caller should use only  
in emergency INVITEs, it may make sense to think about parameters *for  
that Contact URI*. For example, the 'user' parameter may well be  
suitable for that purpose. In any event, this doesn't require a  
separate registration, as this special URI could just be returned  
along with the others, thus reducing the registration signaling load  
by half.

- "Restricted" user: This presumably leads to the whole discussion  
about unauthenticated calls, subject of a different draft.

Henning

On Nov 17, 2008, at 8:11 AM, Milan Patel wrote:

> necessary
> marking

---

From: "Milan Patel" <[email-masked]>
Date: Tue, 18 Nov 2008 17:38:30 -0000

Hi Henning,

Firstly, your previous email you asked:
Why not just have the normal registration be accepted for emergency
calls only, without the parameter?
This is perfectly OK when the user is not roaming. 

At least in 3GPP, the addition of "sos" in the INVITE's contact header
can be associated with the sos URN in the Request-URI. But let's
concentrate on the REGISTER request for now in this email. 

I'll deal with the restricted case first: if you do not have sufficient
credentials to register with the network, you can't register, so yes,
this is similar to the unauthenticated access. In this case, we are
using Equipment identity to identify the user, but doesn't help in the
call-back case. Since the user is not registered at an S-CSCF, there is
no way the call can be routed back to the user. 

Normal user: if the user isn't roaming, and registered as one normally
does. The UE registers with a SIP URI. In the P-Associated-URI in the
200 (OK) to the REGISTER, the UE receives all the identities implicitly
registered by the UE, including a tel-URI. In the event of an emergency,
the user may use any of these identities when initiating an emergency
call. 

Now in the case when the user wasn't registered, or was roaming
(regardless of being registered or not), and has sufficient credentials
to be authenticated by the network, the user makes an emergency call -
the UE registers with the network. It needs to tell the registrar this
registration is due to an emergency call, please don't barr my
identities, or restrict me from roaming. 

Do I need to provide further explanation in the draft on the conditions
for emergency registration? Isn't it sufficient to refer out to 3GPP TS
23.167? 

Cheers,
Milan 

-----Original Message-----
From: Henning Schulzrinne [mailto:[email-masked]] 
Sent: 18 November 2008 16:11
To: Patel, Milan (MOP:EP10)
Cc: DRAGE, Keith (Keith); ECRIT
Subject: Re: [Ecrit] What's up with draft-patel-ecrit-sos-parameter

My general question is whether we need special mechanisms for REGISTER,
as we have enough complexity already. (I won't go into the INVITE case
for now, as that seems to be a more complicated issue and raises a
significant number of fraud prevent issues unless there is no incentive
for non-emergency parties to add a "sos".)

- "Normal" user (not barred from roaming, lacking authentication, ...):
As far as I can tell, the device doesn't do anything different and
wouldn't know about including special Contact headers in any event. The
draft doesn't really specify what happens in that case, as it seems to
focus far too much on syntax and not on behavior. Your note seems to
indicate that the registrar returns some kind of special (tel) URI that
the UA should use as a contact in the call. The draft says "will be
included in the Contact header" - but not by whom.

If we really want special Contact URIs that the caller should use only
in emergency INVITEs, it may make sense to think about parameters *for
that Contact URI*. For example, the 'user' parameter may well be
suitable for that purpose. In any event, this doesn't require a separate
registration, as this special URI could just be returned along with the
others, thus reducing the registration signaling load by half.

- "Restricted" user: This presumably leads to the whole discussion about
unauthenticated calls, subject of a different draft.

Henning

> the emergency caller. If a particular AOR was registered, it is 
> possible to ensure that special handling is applied for this AOR - 
> suppress network based services and barring restrictions. In the 
> Internet Draft, I didn't want to go into all the requirements of 
> registration since these are covered in 3GPP TS 23.167 (which is a 
> normative reference).
>
> 3GPP requirements mandate that barred identities can be used to 
> initiate emergency calls. Roaming resitrctions on any identities 
> registered during emergency call initiation must be lifted so these 
> identities can

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 18 Nov 2008 14:41:40 -0500

Milan,

thanks for your explanation. I think it raises a larger issue: You  
seem to treat this as a 3GPP-specific issue, i.e., something that only  
should be used in the 3GPP case. For example, the P-Associated-URI  
facility is not something available outside that context. In general,  
I consider it a bad idea to have deployment-specific SIP variants,  
even more so in the emergency calling case. The goal should be that  
any SIP terminal can place emergency calls, rather than creating non- 
compatible versions of SIP based on access networks. Maybe we should  
have this larger-issue first before worrying about parameter syntax.

Henning