RE: [Geopriv] HELD and persistent TLS connections in emergency calls

["Winterbottom, James" <James.Winterbottom at andrew.com>]

A call-server is the proxy in the way you are describing it.
I would point out though, that the session between the proxy and the
LoST resolver, does not mean that there is a 'nailed up' session all the
way to the local LoST server, which may still require a session to be
established, and certainly will until the network is fully meshed.
Further more, if the end-point has to do a LoST look up prior to
originating the call, as is suggested by phone BCP, then the problem
still exists.

I think, rather than saying 'hey this is bad', we need a far more
holistic view and not impose totally ridiculous 'out of thin air' time
requirements such as those that have been put forward thus far.

Cheers
James

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs at cs.columbia.edu]
> Sent: Sunday, 16 September 2007 7:53 PM
> To: GEOPRIV
> Subject: Re: [Geopriv] HELD and persistent TLS connections in
emergency
> calls
> 
> In many cases, all of these connections are going to be existing
already
> and are essentially 'nailed up'. For example, the proxy would have a
> long-term connection to the LoST resolver.
> 
> I don't know what a call server is.
> 
> Winterbottom, James wrote:
> > It is unclear to me at least why we are so worried about the
potential
> > 500ms to get setup the location session, when there are at least 2
other
> > TLS SIP sessions to be established, plus a LoST connection from the
> > call-server to check the authenticity of the destination as well.
> >
> > This seems somewhat moot since without valid location you are either
not
> > going route at all, or you are going to misroute.
> 
> 
> _______________________________________________
> Geopriv mailing list
> Geopriv at ietf.org
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]



_______________________________________________
Geopriv mailing list
Geopriv at ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv