Subject: [Ecrit] Service URN Usage (UA Loose Routing)

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 10 Sep 2007 09:21:28 +0200

Hi all,

after some discussions on the usage of the Service URN it seems that 
most people in ECRIT agreed to move forward with the initially planned 
approach. Below, you can find a description of how the Service URN would 
be used in various scenarios.

Are there any objections?

Ciao
Hannes

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

== End Host Procedures ==

* UA does not recognize the emergency call.

To: Dial String
Request URI: Dial String
No Route header

* UA runs LoST and determines the PSAP URI:

Request URI: Service URN
To: Service URN
Route Header: PSAP URI

* UA does not run LoST but recognizes the emergency call.

Request URI: Service URN
To: Service URN
No Route header

== Proxy Procedures ==

* Incoming request contains Service URN; Proxy runs LoST

and determines the PSAP URI

--- Input:

Request URI: Service URN
To: Service URN
No Route header

--- Output:

Request URI: Service URN
To: Service URN
Route Header: PSAP URI

* Incoming request contains Dial String; Proxy runs LoST

and determines the PSAP URI:

--- Input:

Request URI: Dial String
To: Dial String
No Route header

--- Output:

Request URI: Service URN
To: Dial String
Route Header: PSAP URI

Remark: "Dial String" refers to http://tools.ietf.org/html/rfc4967

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 10 Sep 2007 14:33:50 +0200

Hi,

I don't have any objections. I have only clarified how it works in IMS,
and why. It's up to you to decide what/if to do with that information.

Also, in the ECRIT documentation, I think you should indicate that your
solution does not work with MGCs that route the destination number based
on the Request-URI (that is not an IMS specific MGC behavior).

I do have one question for clarification, though: in the examples there
is only one Route header, pointing towards the PSAP. IF there are
intermediate entities that also need to be in the path, is it assumed
that the one inserting the PSAP Route has information about those, in
order to insert Route headers also for those entities if needed?

Regards,

Christer

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: 10. syyskuuta 2007 10:21
> To: IETF SIP List; ECRIT
> Subject: [Ecrit] Service URN Usage (UA Loose Routing)
> 
> Hi all,
> 
> after some discussions on the usage of the Service URN it 
> seems that most people in ECRIT agreed to move forward with 
> the initially planned approach. Below, you can find a 
> description of how the Service URN would be used in various scenarios.
>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 10 Sep 2007 08:42:13 -0400

Hannes,

I'm still worried that because we're using the routing fields for 
marking, there's a risk that proxies will do things to those headers 
that will remove the marking and cause the emergency call to fail.

For instance, I've heard tell that some proxies like to strip all Route 
headers from INVITE messages passing through them.  In your example 
below, that would cause the call to need another LoST lookup, which may 
be impossible if no subsequent proxy supports LoST, or if there's no 
proxy-readable location in the INVITE.  Moreover, if a proxy changes the 
To field or the Request URI, then downstream proxies might not even 
recognize that a LoST lookup is required and thus would cause the call 
to fail.

I don't disagree with the three abstract states you've defined 
(unrecognized, recognized but not routed, and routed), but I would 
prefer that (1) The Service URN were carried in an explicit marking 
field even if a new one has to be created (say, Requested-Service), and 
that (2) after routing (LoST) a call looks like any other call to a PSAP 
URI, but with an explicit marking.  I think this would be much more in 
the spirit of minimal surprise.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 08:51:18 -0400

> and why. It's up to you to decide what/if to do with that information.
I think we understand that.  It may be that the PSAPs will require one or
the other solution in calls placed towards them, but I don't see a big
problem dealing with that.

As I pointed out, the proposed IMS solution does not even meet the existing
specification, let alone anything new.

> on the Request-URI (that is not an IMS specific MGC behavior).
That is correct.  None of ecrit works with TN based routing.  In the U.S. i3
system, it would be required that the MGC arrange a TN to location
translation, followed by a LoST query to obtain a PSAP URI and routing per
normal SIP standards towards the PSAP.

The incoming SIP call will need the Route header in i3 unless we decide to
accept the IMS alternative.  The current version of the i3 specification
does not.

> order to insert Route headers also for those entities if needed?
I would expect that the ESRP could replace the Route header if it needed to.
It could indeed put more than one Route header on the call.

Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 08:57:26 -0400

I think that if you look, you can find proxies that will break anything we
can define.  No matter what we specify, there is sure to be a proxy out
there that breaks it.  For example, there are proxies that strip any header
they don't recognize.  They aren't supposed to, but they do.

It's futile to try and define any new behavior based on what non standard
existing proxies will do.  In this case, they will have to recognize
emergency calls and do the appropriate processing of them.

The test function would find these things, of course.

Brian

> From: Richard Barnes [mailto:[email-masked]]
> Sent: Monday, September 10, 2007 8:42 AM
> To: Hannes Tschofenig
> Cc: IETF SIP List; ECRIT
> Subject: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing)
> 
> Hannes,
> 
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

---

From: Richard Barnes <[email-masked]>
Date: Mon, 10 Sep 2007 09:35:30 -0400

> can define.  ...   For example, there are proxies that strip any header

Sure, but we should try to look at likely failure modes and mitigate 
their impact on emergency calls.  It's in the interest of VSPs to route 
calls to the correct destination (so that their service actually works), 
but it's often not in their interest to route it via the path specified 
in the Route header fields.

So if the PSAP URI were carried in the R-URI/To, and the Service URN 
were carried in another header (even Route), then even a proxy that 
stripped out every header it doesn't like or recognize would still get 
the call to the PSAP (even if the PSAP wouldn't know which service was 
requested).

I thought that this was the point of keeping emergency calling as close 
as possible to normal calling -- that in spite of whatever pathological 
things proxies might do, the call would get through.

> The test function would find these things, of course.

That's true of whatever we define.  For that argument to be applicable 
to a given emergency call, you also need to assume that the UA does 
tests every time the proxy path between it and the PSAP changes.  Of 
course, this could happen without the UA knowing it, so the UA would 
have to be frequently testing.

--Richard

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 09:58:06 -0400

Most carriers have pretty closed systems.  They only route within their own
domain.  Some are now doing inter-carrier routing, but generally that is
with gateway nodes within the domain which connect to some kind of peering
system.  It's not really clear how they will modify this for emergency
calls.  IMS has a separate proxy (E-CSCF) that would handle it.  Others may
make it a function of their gateway proxies.

The Route stripping can happen in a couple of places.  The most common is
the SBC that protects the network from wayward user devices.  The way most
SBCs are set up, I think they will have to be changed for any emergency call
processing; they often don't pass anything that isn't a TN in the R-URI, and
that's where headers not understood in the network are often dropped.

I think the SBC issues are pretty straightforward; some changes are going to
be needed, and if there is a spec, the spec can be accommodated.

Then it depends on how the network is configured.  In my experience, the
next hop routing proxy does most of the work; from there, it's mostly
special processing the nhrp invokes, or the call is on a gateway node next.
Most routing proxies don't drop Route headers, but some that I know of don't
pay any attention to them.  I'd worry a little about those.  The SBC can
preroute (which may be a good idea anyway), or the nhrp element may need an
update.  The call is then probably on some kind of gateway element, which
also can be an SBC.  Again, I don't think any of these drop Route headers,
but some may ignore them.  Whatever it is, it will need at least some
configuration work to get the call out of the carrier domain into the
emergency services domain.

I guess my bottom line is that the networks are going to need some set of
changes to deal with emergency calls at all, and when those changes are
done, the whole thing will work.  I suspect most of this really is
configuration, but if there are code updates needed, I think they will be
needed regardless of which solution we choose.

Brian

> Sent: Monday, September 10, 2007 9:36 AM
> To: Brian Rosen
> Cc: 'Hannes Tschofenig'; 'IETF SIP List'; 'ECRIT'
> Subject: Re: [Sip] Re: [Ecrit] Service URN Usage (UA Loose Routing)
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 10 Sep 2007 10:42:24 -0400

I agree with your sentiment.

I don't see how the access network is in the calling path at all unless it's
an IMS-like system where that is the agreement.  In that case, by
definition, the access network has a relationship with the calling network.
Normally, the UA's proxy discovery mechanism leads it to its calling
network, not anything in the access network.

I think if it happened accidently, it would work; no matter who routes it,
the PSAP URI leads to the right place.

Brian

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, September 10, 2007 10:29 AM
> To: Brian Rosen
> Cc: 'Richard Barnes'; 'Hannes Tschofenig'; 'IETF SIP List'; 'ECRIT'
> Brian,
> I agree that there will be implementations that break whatever rules we
> make. But does that mean we should make no rules?
> 
> In this case it isn't even a matter of making a new rule - it is an old
> one I am talking about.
> 
> But the key here is to ensure that when we develop use cases, examples,
> etc. they don't break this rule. If a practical system will require
> breaking the rule then IMO another mechanism is needed.
> 
> The case that concerns me most here is when a UA is connected through an
> access network that is different from its home network. Then the access
> network preemptively decides that a particular R-URI looks like an
> emergency number in its domain, and acts accordingly, even though the
> R-URI isn't within the domain of the access network.
> 
> The point here of course is that there are no universal standards for
> the user part of SIP URIs. So there is no way that a proxy not
> responsible for the domain of the URI to decide that the user part is a
> dial string at all, and not something else. (Well, user=dialstring *is*
> a standard for the user part, but it *explicitly* is intended only for
> use within the responsible domain.)
> 
> In such a case, either the UA should be using the domain of the access
> network when constructing dial strings, or else the access network
> should have a business relationship with the home network that is
> sufficient for the access network to claim responsibility for the domain
> of the R-URI.
> 
> 	Paul
> 
> Brian Rosen wrote:

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 11 Sep 2007 12:14:48 +0200

Hi Brian,

~snip~
> accept the IMS alternative.  The current version of the i3 specification

Do you think we should mention this in the framework document?

Ciao
hannes

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Sep 2007 08:22:35 -0400

No, I think TN based routing is national-variant defined, and out of scope
for this work.

Brian

> Sent: Tuesday, September 11, 2007 6:15 AM
> To: Brian Rosen
> Cc: 'Christer Holmberg (JO/LMF)'; 'ECRIT'
> Subject: Re: [Ecrit] Service URN Usage (UA Loose Routing)
> 
> Hi Brian,
> 
> ~snip~

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 11 Sep 2007 14:28:57 +0200

Hi,

I think it should be mentioned. Because, whether it's in the scope or
not, I think it is an important thing to note.

Regards,

Christer

> From: Brian Rosen [mailto:[email-masked]] 
> Sent: 11. syyskuuta 2007 15:23
> To: 'Hannes Tschofenig'
> Cc: Christer Holmberg (JO/LMF); 'ECRIT'
> Subject: RE: [Ecrit] Service URN Usage (UA Loose Routing)
> 
> No, I think TN based routing is national-variant defined, and 
> out of scope for this work.
> 
> Brian
> 
> > >> Also, in the ECRIT documentation, I think you should 
> indicate that 
> > >> your solution does not work with MGCs that route the destination 
> > >> number
> > based
> > > That is correct.  None of ecrit works with TN based 
> routing.  In the
> > U.S. i3
> > > translation, followed by a LoST query to obtain a PSAP URI and 
> > > routing
> > per
> > > The incoming SIP call will need the Route header in i3 unless we 
> > > decide
> > to
> > > accept the IMS alternative.  The current version of the i3 
> > > specification does not.
> > >
> > >
> >

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 11 Sep 2007 08:47:10 -0400

Okay, I can't see any harm.  I'll put it in.  Something like:

There are many legacy telephone networks which will persist long after most
systems have been upgraded to IP origination and termination of emergency
calls.  There will be PSAPs which require new systems to terminate to
existing mechanisms for some time.   Many of these legacy systems use
telephone number based routing.  Gateways and conversions between existing
systems and newer systems defined by this document will be required.  Since
existing systems are governed primarily by local government regulations and
national standards, the gateway and conversion details will be governed by
national standards and thus are out of scope for this document.

Brian
> From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]
> Sent: Tuesday, September 11, 2007 8:29 AM
> To: Brian Rosen; Hannes Tschofenig
> Cc: ECRIT