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:[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ecrit
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
