Ugh, yes, how silly of me.
Today, routing is based on the trunk line you place the call on. That won't
work if the Internet is the trunk - you have to route based on location.
Duh!
By the way, it means that location has to be sent in such a way that the SIP
element(s) that make the routing decisions is able to look at the
information.
This means that it must have the key for any crypto. That complicates
both authentication and confidentiality.
Well, that's a pretty hard requirement - routing must be based on
location, thus it must be in the first (INVITE) message, and has to
be decryptable (quickly and with great reliability) by routing
elements (proxy servers) along the path. We've agreed among
the folks working on emergency calls in SIP that we will have few such
elements (so that emergency calls are not dependant on very many things
working), but it will be more than one element in some cases for sure.
Brian
> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Wednesday, April 03, 2002 8:45 AM
> To: Rosen, Brian
> Cc: 'Andrew Daviel'; 'geopriv@mail.apps.ietf.org'
> Subject: Re: crypto delay (Notes from Non-meeting)
>
>
> I don't think that's a viable option. The location information is used
> for two different things:
>
> - selecting the appropriate emergency call center that handles a
> particular geographic region (PSAP in the US);
>
> - providing the emergency call center with user location information
>
> Clearly, the first requires location information as part of the call
> setup and cannot be deferred until later in the call.
>
> >
> > I'll conceed the point that it's possible to have the
> location information
> > come later than the call completion. That is undesirable (because
> > it is actually very interesting to route the call in the
> emergency center
> > based on location, something not possible now), but it's
> concievable.
> > It's also not a great way to deal with in in SIP - rather
> than simply
> > shoving the location in the INVITE, we have to create a mid
> call dialog.
> > That is also possible, if undesirable.
> >
> > Brian
>
Received on Wed Apr 3 08:59:41 2002
This archive was generated by hypermail 2.1.8 : Thu Jan 22 2004 - 12:32:23 EST