Re: [Ecrit] Direct access - the "normal" call-path

[Brian Rosen <[e-mail]>]

First of all, Ray, if your normal call path is direct over the Internet,
send it direct over the Internet.  "We" (at least North American PSAPs
upgraded to NG9-1-1) will take them.

There may end up being some kind of formal introduction process involving
testing, and possibly a credential, but we haven't worked anything like that
out yet.  Calls would be accepted from unknown sources as long as there
wasn't an attack in progress which we didn't have better filtering for.  As
I mentioned before, we may end up with some transitive trust mechanisms such
that if the U.K. PSAP upgraded to IP connectivity compatible with phonebcp,
and you had a credential they trusted, the U.S. PSAPs may trust you.

That might occur if one of your employees came to the U.S. and used your PBX
with a softclient from a Starbucks.  It will work.

Such mechanisms aren't described in phonebcp.  I don't think they have to
be.  We're not looking for any phone behavior, and since all we are looking
for in the proxy is TLS with mutual auth, we don't need anything there for
proxies either.

I want calls sent on the normal call path: through whatever proxies you
normally use.  They have to route per the Route headers and Request URI of
course.  Sounds like that would be what you normally do, which is good.

Right now, you send 999 calls over the PSTN.  I do hope you will have "SIP
Trunking" to replace your E1s or whatever your PSTN connection is now.  We
would prefer your emergency calls to come that way, through your carrier, as
they do now.  But if you have a good reason to send them direct, do it as
long as they meet phonebcp requirements.  We'd LOVE a good Identity header
btw.

Brian




On 11/11/09 1:30 AM, "Dawson, Martin" <[e-mail]> wrote:

> An emergency call is not "normal" so "normal" isn't an argument - nor a
> panacea.
> 
> If a domain/UA is so locked down that SIP invites can only go to a specific
> proxy then that's either a proxy scenario (not direct) or the domain should
> also have LoST locked down so the PSAP URI points at the proxy it wants... it
> can look like direct to the client but still be proxy.
> 
> There's plenty to be said for the proxy using the direct recommendations as
> well. Having an emergency specific proxy registration (on behalf of the UA)
> has benefits in terms of ability to prioritise call back. I don't think this
> draft is in conflict with phonebcp.
> 
> If the jurisdiction can't afford the horsepower to support the
> registration/callback then they don't have to. The facility is negotiated; it
> has to be. I'm sceptical that it's as significant as all that.
> 
> Heck yes, applying policy based on location (by value or reference) is
> recommended. Direct mode simplifies these considerations.
> 
> I'm still waiting for someone to point me at the part of phonebcp that
> explains how VSPs/proxies are supposed to be authenticated/authorized in order
> for this subscriber identity validation to occur. I honestly never thought
> that was part of the requirements or in scope; it's a recent addition from my
> perspective. I thought that the typical "proxy" that we were referring to was
> an enterprise soft switch - not arbitrary foreign VSPs.
> 
> Cheers,
> Martin
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> James M. Polk
> Sent: Wednesday, 11 November 2009 4:43 PM
> To: [e-mail]; ecrit
> Subject: Re: [Ecrit] Direct access - the "normal" call-path
> 
> Ray
> 
> What's the normal SIP signaling flow between your SIP UA (i.e.,
> phone) and another SIP UA?
> 
> Does this go through a proxy server?
> 
> Does it have to go through a proxy server?
> 
> Do you agree that some customers would want to lock UAs into
> communicating through a certain domain proxy server before it proxies
> that signaling out towards its ultimate destination UA?
> 
> Now, with "Direct", any UA can register with a Emergency Services
> Routing Proxy (ESRP). Let's call this an Emergency Services Registrar or
> "ESR".
> 
> The purpose of an Registrar is to populate a logical location
> database with the host-id of the UA, and link that with the user's
> URI and the IP address -- thus creating at least 3 entries for the
> Proxy to refer to when looking up a SIP request to determine if it
> knows a path or destination UA (by IP address) to send this SIP
> request towards.
> 
> Any UA probably has already done this within their own domain, with
> that domain's Registrar - so that UA can receive SIP requests
> forwarded by that domain's proxy server.
> 
> What I understand this ID wanting to accomplish is allowing a UA to
> register to more than one domain (which I normally don't have an
> issue with), but that second domain to only be used by a certain
> application -- based on attempts to contact the sos URN (i.e. dialing
> 911 or 112 or 999, depending on where you are).
> 
> Now, if your UA's domain is open and free of access, this will not be
> a problem.
> 
> But, if your domain is more constrained, your first hop proxy server
> for sos calls just might have a problem being contacted, because it
> is outside of a trust boundary -- i.e., you attempt to directly
> contact the ESRP without going through any internal domain proxy or
> B2BUA or SBC first.  This can be a problem.
> 
> This also flies in the face of what phoneBCP is currently defining --
> which isn't really that great -- because most of what we should be
> doing is complementary.
> 
> Besides, imagine the cost of resources it'll take to operate this
> ESR, with all these registrations -- that really can't be rejected,
> unless you want to restrict them to having to be within a location
> region.  That means a PIDF-LO will have to be in the REGISTER request
> to the ESR, which is not normal.  All that state information...
> that's gonna be a hunking machine in major metropolitan areas.
> 
> unless i'm missing something...
> 
> James
> 
> At 08:17 PM 11/10/2009, [e-mail] wrote:
>> Regarding Brian's comments in the WG session -
>> 
>> Our corporate PBX does *not* have a subscription to a SIP VSP, and
>> as far as I know never will.
>> 
>> Our "normal" call-path for any SIP URI is to send the call *direct*
>> to the SIP server listed in the domain's SRV records.
>> 
>> If we had to follow the "use a VSP" rule then the only fallback for
>> us would be to send the call over the PSTN, which rather defeats the point.
>> 
>> In the UK the partial integration of PSAPs into the VoIP world is
>> currently only possible because the number of VSPs with direct PSTN
>> interconnect is very limited (< 20, AFAIK) and because in the
>> interim all ES calls arrive over PSTN.
>> 
>> The remaining VSPs that only have IP connectivity number in the
>> several hundreds.  Since (as above) ES calls have to go over the
>> PSTN they then have to route the call via one of the 20 that does
>> have PSTN interconnect.
>> 
>> We've *already* got a scale problem - it's not feasible for the
>> PSAPs to recognise all of the existing UK-based VSPs, let alone the
>> many thousands more that lie outside of our national jurisdiction.
>> 
>> Given these circumstances ECRIT-direct makes a lot of sense, IMHO.
>> 
>> Ray
>> _______________________________________________
>> Ecrit mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit