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.

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




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Hannes,

The scenarios seem pretty reasonable to me, with one
qualification on 
the last one:

If the R-URI contains a "dial string" then the
proxy may replace it with 
a Service URN if the proxy is responsible for the domain of
the service 
URN. That of course assumes that the "dial string"
is encoded as a SIP 
URI, rather than a TEL URI. (But that seems most likely
since there is 
no standard way to encode a dial string as a TEL URI.)

If the proxy is not responsible for the domain of the dial
string then 
it can't relace the R-URI. That is a rule that I think we
*must* 
preserve. Only a node responsible for the domain is allowed
to interpret 
the user part, including determining that it is an emergency
number.

	Paul

Hannes Tschofenig wrote:
> 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
> 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:Hannes.Tschofeniggmx.net]

> 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.
> 
> 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
> Ecritietf.org
> https://
www1.ietf.org/mailman/listinfo/ecrit
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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



Hannes Tschofenig wrote:
> 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
> Ecritietf.org
> https://
www1.ietf.org/mailman/listinfo/ecrit
> 
> 



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

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

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



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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


> -----Original Message-----
> From: Richard Barnes [mailto:rbarnesbbn.com]
> 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,
> 
> 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
> 
> 
> 
> Hannes Tschofenig wrote:
> > 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
> > Ecritietf.org
> > https://
www1.ietf.org/mailman/listinfo/ecrit
> >
> >
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

> I think that if you look, you can find proxies that
will break anything we
> can define.  ...   For example, there are proxies that
strip any header
> they don't recognize.  They aren't supposed to, but
they do.

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




> 
> Brian
> 
> 
>> -----Original Message-----
>> From: Richard Barnes [mailto:rbarnesbbn.com]
>> 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,
>>
>> 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
>>
>>
>>
>> Hannes Tschofenig wrote:
>>> 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
>>> Ecritietf.org
>>> https://
www1.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol
>> Use sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip
> 
> 
> 



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

> -----Original Message-----
> From: Richard Barnes [mailto:rbarnesbbn.com]
> 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)
> 
> > I think that if you look, you can find proxies
that will break anything
> we
> > can define.  ...   For example, there are proxies
that strip any header
> > they don't recognize.  They aren't supposed to,
but they do.
> 
> 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
> 
> 
> 
> 
> >
> > Brian
> >
> >
> >> -----Original Message-----
> >> From: Richard Barnes [mailto:rbarnesbbn.com]
> >> 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,
> >>
> >> 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
> >>
> >>
> >>
> >> Hannes Tschofenig wrote:
> >>> 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
> >>> Ecritietf.org
> >>> https://
www1.ietf.org/mailman/listinfo/ecrit
> >>>
> >>>
> >>
> >>
> >>
_______________________________________________
> >> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core
SIP Protocol
> >> Use sip-implementorscs.columbia.edu for
questions on current sip
> >> Use sippingietf.org for new
developments on the application of sip
> >
> >
> >



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:
> 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
> 
> 
>> -----Original Message-----
>> From: Richard Barnes [mailto:rbarnesbbn.com]
>> 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,
>>
>> 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
>>
>>
>>
>> Hannes Tschofenig wrote:
>>> 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
>>> Ecritietf.org
>>> https://
www1.ietf.org/mailman/listinfo/ecrit
>>>
>>>
>>
>>
>> _______________________________________________
>> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP
Protocol
>> Use sip-implementorscs.columbia.edu for
questions on current sip
>> Use sippingietf.org for new developments on the
application of sip
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol
> Use sip-implementorscs.columbia.edu for
questions on current sip
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivatcisco.com]
> Sent: Monday, September 10, 2007 10:29 AM
> To: Brian Rosen
> Cc: 'Richard Barnes'; 'Hannes Tschofenig'; 'IETF SIP
List'; 'ECRIT'
> Subject: Re: [Sip] Re: [Ecrit] Service URN Usage (UA
Loose Routing)
> 
> 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:
> > 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
> >
> >
> >> -----Original Message-----
> >> From: Richard Barnes [mailto:rbarnesbbn.com]
> >> 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,
> >>
> >> 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
> >>
> >>
> >>
> >> Hannes Tschofenig wrote:
> >>> 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
> >>> Ecritietf.org
> >>> https://
www1.ietf.org/mailman/listinfo/ecrit
> >>>
> >>>
> >>
> >>
> >>
_______________________________________________
> >> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core
SIP Protocol
> >> Use sip-implementorscs.columbia.edu for
questions on current sip
> >> Use sippingietf.org for new
developments on the application of sip
> >
> >
> >
> > _______________________________________________
> > Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol
> > Use sip-implementorscs.columbia.edu for
questions on current sip
> > Use sippingietf.org for new developments on the
application of sip
> >



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip