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

From: [email-masked]
Date: Wed, 11 Nov 2009 11:17:27 +0900

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

---

From: [email-masked]
Date: Wed, 11 Nov 2009 11:28:59 +0900

I should clarify (insufficient sleep last night) -

Most of what I just wrote relates to a *future* world where the UK PSAPs 
are IP-connected.  That's when we'd really have the scale problem that 
ECRIT-direct (indirectly) resolves, in-so-much as ECRIT-direct fixes the 
VSP-trust network scaling problem by implicitly trusting *everybody*.

At the moment it's moot because in the interim all ES calls have to go 
over the PSTN anyway.

Ray

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 10 Nov 2009 23:43:20 -0600

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, [email-masked] wrote:
>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.
>
>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.
>
>_______________________________________________
>Ecrit mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Dawson, Martin" <[email-masked]>
Date: Wed, 11 Nov 2009 14:30:51 +0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of James M. Polk
Sent: Wednesday, 11 November 2009 4:43 PM
To: [email-masked]; ecrit
Subject: Re: [Ecrit] Direct access - the "normal" call-path

Ray

James

---

From: Brian Rosen <[email-masked]>
Date: Wed, 11 Nov 2009 10:32:34 -0500

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" <[email-masked]> wrote:

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