Subject: Re: [speermint] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling

From: "Stastny Richard" <[email-masked]>
Date: Fri, 16 Jun 2006 22:11:54 +0200

I could live with this proposal
 
-sta

________________________________

Von: Michael Hammer (mhammer) [mailto:[email-masked]]
Gesendet: Fr 16.06.2006 21:44
An: Jean-Francois Mule; Hannes Tschofenig; Pfautz, Penn L, GBLAM
Cc: Stastny Richard; [email-masked]
Betreff: RE: [speermint] minimum set ofrequirements forSIP-basedVoIPinterconnection and emergency calling

All,

Let me ask the question a different way:

Will all PSAPs belong to the same federation (a special PSAP federation
that defines the rules for accessing PSAP domains), or

will all PSAPs belong to various federations, where the rules for
handling SIP messages and what is needed for SOS calls is defined by
each federations?

Put me in the column for holding off on special cases of calls being
addressed until we have worked out the basic call case.  By then,
perhaps the ECRIT WG will have made further progress on the SOS call
delivery mechanisms and associated protocol elements.

Mike

> -----Original Message-----
> From: Jean-Francois Mule [mailto:[email-masked]]
> Sent: Friday, June 16, 2006 9:39 AM
> To: Hannes Tschofenig; Pfautz, Penn L, GBLAM
> Cc: Stastny Richard; [email-masked]
> Subject: RE: [speermint] minimum set ofrequirements
> forSIP-basedVoIPinterconnection and emergency calling
>
> Penn and Hannes,
>
>    Thanks for the input. Here is an attempt to clarify what
> could be in scope of speermint.
>
> Hannes wrote:
> > It might be good to clearly describe what you want to
> accomplish with
> > emgerency services in the context of peering.
>
> The potential goal would be to write the minimum requirements
> a VSP should comply with when handing off an emergency call
> to another administrative domain over IP through a VoIP
> interconnect point (SIP call termination to another
> third-party provider which in turn does terminate the call to a PSAP).
>
>    Folks assume the work in GEOPRIV and ECRIT takes care of the above.
> The requirement gap I can see so far is based on:
> a) the requirement work in ECRIT is for IP-enabled PSAPs (US/nena i3).
> The ECRIT requirement document states:
> | This document only focuses on end-to-end IP-based calls,
> i.e., where
> | the emergency call originates from an IP end system and terminates
> | into an IP-capable PSAP, conveyed entirely over an IP network.
>
> b) GEOPRIV, ECRIT and SIPPING are concerned with location
> determination, emergency context resolution, location-based
> routing of the SIP call to the PSAP URI, location conveyance in SIP.
>
> c) SPEERMINT is about "architectures to identify, signal, and
> route delay-sensitive (real-time) communication sessions."...
> "These sessions use the SIP signaling protocol to enable
> peering between two or more administrative domains over IP networks."
>
> So, for example, the speermint requirement doc could state
> things like:
>       - any applicable ECRIT requirements for exchanging
> emergency sip calls between 2 or more domains,
>       - any SIP requirements that should be taken into consideration.
> For e.g. if available, convey location using sipping location
> conveyance. But also special handling of things like
> p-asserted-id when handing off emergency calls (if privacy is
> on in the originating domain, some VSPs remove p-asserted-id
> when handing out the call to another provider). In the case
> of an emergency call, for psap callback, p-asserted-id
> must/should be left in... so that the terminating VSP that
> connects to the PSAPs can identify the ANI.
>
> These are first thoughts to provide more examples. We could
> just have a couple of sentences highlighting the key
> requirements and giving pointers to consider when the handoff
> of emergency calls is possible.
>
> Penn wrote:
> > > I think we'd be better served NOT to take up the
> emergency use case
> > for
> > > now, until the other groups (GEOPRIV and ECRIT) solidify their
> > > requirements.
> This is fine and I'm ok not taking if we think we should just
> not take this for *now* but as Hannes points out, and as I
> tried to highlight above, we should not assume there will be
> a lot more requirement work in other IETF groups around the
> SIP interconnects and there may be some gaps (hence the scope
> question).
>
> Jean-Francois
>
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:[email-masked]]
> > Sent: Friday, June 16, 2006 6:10 AM
> > To: Pfautz, Penn L, GBLAM
> > Cc: Jean-Francois Mule; Stastny Richard; [email-masked]
> > Subject: Re: [speermint] minimum set of requirements forSIP-
> > basedVoIPinterconnection and emergency calling
> >
> > The requirements work in ECRIT is finished. Here is the most recent
> > document:
> > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-
> > 10.txt
> >
> > It might be good to clearly describe what you want to
> accomplish with
> > emgerency services in the context of peering.
> >
> > Ciao
> > Hannes
> >
> >
> > Pfautz, Penn L, GBLAM wrote:
> > > I think we'd be better served NOT to take up the
> emergency use case
> > for
> > > now, until the other groups (GEOPRIV and ECRIT) solidify their
> > > requirements.
> > >
> > > Penn
> > >
> > > -----Original Message-----
> > > From: Jean-Francois Mule [mailto:[email-masked]]
> > > Sent: Friday, June 16, 2006 7:39 AM
> > > To: Stastny Richard
> > > Cc: [email-masked]
> > > Subject: RE: [speermint] minimum set of requirements
> > > forSIP-basedVoIPinterconnection and emergency calling
> > >
> > > Stastny Richard wrote:
> > >
> > >>>Some VSPs do have gateways connected to the PSTN and the whole
> > >>
> > >>selective routers thingy in the North American system for >example
> > to
> > >>do this; some don't and hand off the call to another VSP. The
> > question
> > >>of who does the ECRIT mapping protocol >resolution is also not
> > >>relevant here.
> > >>
> > >>Ok, but you mention here two issues out of speermint
> scope: gateways
> > >>to the PSTN and North American selective router stuff
> > >
> > >
> > > And that is clearly out of scope.
> > > Per my earlier email, the scope question was related to the other
> > case
> > > where emergency calls are not handled within a single VSP
> domain (or
> > for
> > > that matter, the case of an enterprise using a SIP interconnect
> > service
> > > and handing off all calls to the VSP).
> > >
> > > Jean-Francois.
> > >
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > > _______________________________________________
> > > Speermint mailing list
> > > [email-masked]
> > > https://www1.ietf.org/mailman/listinfo/speermint
> > >
> > >
>
>
>
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
>

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: "Uzelac, Adam" <[email-masked]>
Date: Fri, 16 Jun 2006 16:17:08 -0400

I agree that focus on initial call flows is wise for the time being, but
what's the harm in citing the requirement with fairly high-level generic
wording for now?!?!  FWIW - I join Mike in the
"holding-off-a-bit-until-we-sort-out-basic-functionality" column.
Crawl-Walk-Run.

-AU

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Friday, June 16, 2006 4:12 PM
To: Michael Hammer (mhammer); Jean-Francois Mule
Cc: [email-masked]
Subject: Re: [speermint] minimum set
ofrequirementsforSIP-basedVoIPinterconnection and emergency calling

-sta

Betreff: RE: [speermint] minimum set ofrequirements

All,

Mike

>    Thanks for the input. Here is an attempt to clarify what could be 
> in scope of speermint.
>
> Hannes wrote:
> The potential goal would be to write the minimum requirements a VSP 
> should comply with when handing off an emergency call to another 
> administrative domain over IP through a VoIP interconnect point (SIP 
> call termination to another third-party provider which in turn does 
> terminate the call to a PSAP).
>
> determination, emergency context resolution, location-based routing of

> the SIP call to the PSAP URI, location conveyance in SIP.
>
> c) SPEERMINT is about "architectures to identify, signal, and route 
> delay-sensitive (real-time) communication sessions."...
> "These sessions use the SIP signaling protocol to enable peering 
> between two or more administrative domains over IP networks."
>
> So, for example, the speermint requirement doc could state things 
> like:
>       - any applicable ECRIT requirements for exchanging emergency sip

> calls between 2 or more domains,
> conveyance. But also special handling of things like p-asserted-id 
> when handing off emergency calls (if privacy is on in the originating 
> domain, some VSPs remove p-asserted-id when handing out the call to 
> another provider). In the case of an emergency call, for psap 
> callback, p-asserted-id must/should be left in... so that the 
> terminating VSP that connects to the PSAPs can identify the ANI.
>
> These are first thoughts to provide more examples. We could just have 
> a couple of sentences highlighting the key requirements and giving 
> pointers to consider when the handoff of emergency calls is possible.
>
> Penn wrote:
> This is fine and I'm ok not taking if we think we should just not take

> this for *now* but as Hannes points out, and as I tried to highlight 
> above, we should not assume there will be a lot more requirement work 
> in other IETF groups around the SIP interconnects and there may be 
> some gaps (hence the scope question).
>
> Jean-Francois
>

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 19 Jun 2006 09:40:11 -0400

I can too.

I do think it will be fairly common for an originating network to hand off
an emergency call to another network.  That network may be one operated by
or for the PSAP, but it will operate much like any other SP.  It probably
will have at least two different mechanisms for interconnect: one very much
a "peering" relationship, well within the scope of speermint, and the other
pretty much an open Internet connection most times accepting any call sent
to it.  The security profiles of these two mechanisms will be different.

However, it's not clear to me whether ecrit takes the speermint work and
runs with that, speermint takes ecrit work and puts words in its document,
or we leave it to the authorities and their own standards groups to do that
work, as we are talking about precisely how a call is handed from an SP to a
PSAP, and the PSAP side of that is governed by the emergency authorities.  I
think ecrit is definitely going to precisely specify the open Internet
interconnect.  It may be that this whole area collapses easily into the
basic speermint model, except for the location header and any priority/QoS
stuff that is peculiar to emergency calls.

Brian

-----Original Message-----
From: Stastny Richard [mailto:[email-masked]] 
Sent: Friday, June 16, 2006 4:12 PM
To: Michael Hammer (mhammer); Jean-Francois Mule
Cc: [email-masked]
Subject: Re: [speermint] minimum set

-sta

All,

Mike