Brian Rosen wrote:
I agree with your sentiment.
I don't see how the access network is in the calling path at all
There have been a lot of topologies discussed from time to time. Who
knows what might be out there?
unless it's
an IMS-like system where that is the agreement.
Even in IMS I wonder if there is that level of agreement, about dial
strings. I haven't seen much evidence of that.
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.
If the UAC has detected the emergency call and put in the Route headers,
or even just put in the service URN, then there isn't a problem. It is
when that isn't the case that is the issue.
IMO, if the UAC wants to have the access proxy second guessing whether
its dial strings are emergency numbers in the access network then it
should be using the domain of the access network to represent its dial
strings. (Then the access network can translate to something in the home
network based on some agreement.)
Paul
Brian
-----Original Message-----
From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
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:[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
