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:[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
_______________________________________________
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
