[Sipconnectit] [SIPForum-techwg] SIPconnect v1.1 changes for emergency services

Tue Apr 3 09:58:57 EDT 2012

When we finalized the document GRUU was not ready and we collectively
decided not to hold up 1.1 waiting for it.  Technical Profiles, remember,
are a snapshot of standards at a point in time.  The larger issue was
implicit registration in 6140

From: sipconnectit-bounces at sipforum.org
[mailto:sipconnectit-bounces at sipforum.org] On Behalf Of Asveren, Tolga
Sent: Tuesday, April 03, 2012 12:11 AM
To: Brian Rosen; Hadriel Kaplan
Cc: sipconnectit at sipforum.org; techwg at sipforum.org; Martin Thomson;
Tschofenig, Hannes (NSN - FI/Espoo)
Subject: Re: [Sipconnectit] [SIPForum-techwg] SIPconnect v1.1 changes for
emergency services

Just one concern: So far GRUU wasn't mentioned anywhere in the specification
AFAIK. Would the proposed text optionally introduce any responsibility on
SSP regarding GRUU support? 

Thanks,

Tolga

From: Brian Rosen [mailto:br at brianrosen.net] 
Sent: Monday, April 02, 2012 6:08 PM
To: Hadriel Kaplan
Cc: Asveren, Tolga; <sipconnectit at sipforum.org>; <techwg at sipforum.org>;
Tschofenig, Hannes (NSN - FI/Espoo); Martin Thomson
Subject: Re: [SIPForum-techwg] SIPconnect v1.1 changes for emergency
services

Sounds good to me.

Brian

On Apr 2, 2012, at 5:58 PM, Hadriel Kaplan wrote:

No problems as far as SIPconnect goes, but SIPconnect only defines the
Enterprise-to-SSP connection.  So if the SIP-PBX gives out a Contact-URI of
any form in an INVITE to the SSP, there's no way in SIPconnect to require
that Contact-URI be passed unchanged to a PSAP somewhere else further
downstream (nor would we want to really, since it often won't work).

So I think for SIPconnect all we have to say is something like:

For emergency service calls, the SIP-PBX MUST use a Contact-URI in the
initial INVITE that can be referenced later in an out-of-dialog INVITE
request's Request-URI to reach the same calling party end device (i.e, the
same SIP UA or handset).  The Contact-URI MUST be usable for at least 5
minutes after the original INVITE dialog ends.  The purpose of this is to
enable emergency service personnel to call back the same phone/device that
made the emergency service call, in case the call is disconnected.  One way
to achieve this is to use a Contact-URI that is either a GRUU, or has
properties similar to a GRUU, such that the SIP-PBX can use the URI in an
incoming INVITE Request-URI to route an incoming call to the same endpoint
instance.  Likewise, the SSP MUST support some means of remembering the
Contact-URI given by the SIP-PBX from the emergency service INVITE, so that
it can use it for an out-of-dialog INVITE back to the SIP-PBX in cases of
emergency service callbacks.  How the SSP accomplishes this internally is
beyond the scope of SIPconnect.

Any thoughts/objections/comments?

-hadriel

On Apr 2, 2012, at 2:36 PM, Asveren, Tolga wrote:

I assume that we can rely on the URI parameters present in the Contact of
the original call being present in the Request-URI of the subsequent call
though. Does anybody see any problem/risk on this one?

Thanks,

Tolga

From: Brian Rosen [mailto:br at brianrosen.net] 
Sent: Monday, April 02, 2012 2:06 PM
To: Asveren, Tolga
Cc: Hadriel Kaplan; sipconnectit at sipforum.org; techwg at sipforum.org;
Tschofenig, Hannes (NSN - FI/Espoo); Martin Thomson
Subject: Re: [SIPForum-techwg] SIPconnect v1.1 changes for emergency
services

It's a new call, so I don't think that would be possible.

Brian

On Apr 2, 2012, at 1:42 PM, Asveren, Tolga wrote:

Can we rely on route set entries from the original call to be used for such
a subsequent call?

Thanks,

Tolga

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
Behalf Of Hadriel Kaplan
Sent: Monday, April 02, 2012 9:46 AM
To: Brian Rosen
Cc: sipconnectit at sipforum.org; techwg at sipforum.org; Tschofenig, Hannes (NSN
- FI/Espoo); Martin Thomson
Subject: Re: [SIPForum-techwg] SIPconnect v1.1 changes for emergency
services

OK, I'll add some wording to that effect.  What happens if the target
Contact fails (e.g., isn't reachable) - should the SIP-PBX route it to any
contact for the same AoR, a default AoR/number (e.g., a main number), or
just reject it and let the PSAP re-try to another target?

-hadriel

On Apr 2, 2012, at 9:11 AM, Brian Rosen wrote:

One requirement that it occurs to me we may not have touched on is call
back: the call must contain a globally routable Contact that reaches the
device, and that contact must remain valid for several minutes beyond the
end of the call to allow a callback in the case of a  pre-mature disconnect.

Brian

On Apr 1, 2012, at 2:34 PM, Hadriel Kaplan wrote:

Howdy,
At last week's IETF meeting in Paris, a meeting was held between several
folks who participated in the creation of SIPconnect v1.1, and folks
involved in NENA and EENA emergency services.  

Based on that discussion, we believe the changes to SIPconnect v1.1 boil
down to the following:
1) The SP-SSE must support the sos URN, in addition to the currently
required support for the basic digit string.  No requirements are placed on
the SIP-PBX.

2) The SP-SSE must not reject SIP messages containing multipart MIME bodies,
for emergency services.  What the SSP does with them internally is beyond
the scope of SIPconnect.  No requirements are placed on the SIP-PBX.

3) The SP-SSE must not reject SIP messages containing the Call-Info,
Geolocation, or Geolocation-Routing header fields, for emergency services.
What the SSP does with them internally is beyond the scope of SIPconnect.
No requirements are placed on the SIP-PBX.

4) The SIP-PBX must not indicate REFER method support in the Allow header
field, if it does not actually support REFER-based call transfer from the
SSP.

The attached SIPconnect 1.1b v1 document is a first draft for documenting
those changes.

It also makes the changes for the security issue identified by Olle
Johansson in a previous email to this mailing list, whereby a REGISTER for
an unknown AoR should be treated the same as a REGISTER for a valid/known
AoR, for obvious reasons. (we had actually identified that issue before as
well, but didn't fix it for some reason)

-hadriel

<SIPconnect 1.1b v1.doc>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/sipconnectit/attachments/20120403/c5aa9302/attachment.html 