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

Tue Apr 3 12:29:01 EDT 2012

Not sure whether this would fall into "major change" category but could
it be possible to mandate that hostpart of the Contact for calls from
IP-PBX is the same as the hostpart of the Contact used during IP-PBX
registration? Similar requirement for the static mode probably would be:
Contact hostpart for calls from IP-PBX should be populated with the
value to be used by SSP as the hostpart of the calls it sends to IP-PBX
direction. Alternatively it can be said that IP-PBX should not use/rely
on hostpart to make the Contact useful to reach the same device for a
subsequent call.

I know it doesn't sound elegant but this could make things a bit more
real-life friendly on the SSP side and probably does not put any
restriction which would matter in practice.

Thanks,

Tolga

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Richard Shockey
Sent: Tuesday, April 03, 2012 10:07 AM
To: 'Brian Rosen'; 'Hadriel Kaplan'; 'Spencer Dawkins'
Cc: sipconnectit at sipforum.org; techwg at sipforum.org; 'Tschofenig, Hannes
(NSN - FI/Espoo)'; 'Martin Thomson'
Subject: Re: [SIPForum-techwg] [Sipconnectit] SIPconnect v1.1 changesfor
emergency services

+1   I never liked GRUU's either.  

We need the text so Spencer can maintain the document. He was the
original document editor and now will oversee all SIPforum technical
TG's

I have to call for a procedure here at some point.   This is going to
mean a reballot of the document among the original TG. 

Then the Board will have to approve.  This will not IMHO slow down the
SIPconnectit work.  

The Board has approved the formation of the SIPconnect Interoperability
Certification [SC-IT] Task Group so it can begin ASAP.  What we have
here is clarification not a fundamental change in 1.1.

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

I agree.  The PBX has to send the SSP a contact that will reach the
calling endpoint.  The SSP has to make sure the call has a contact that
will result in the  call back INVITE getting to the right SIP trunk with
the right To:.  How they do that is up to them, and they don't need any
further standards to accomplish that.  

Brian

On Apr 3, 2012, at 8:00 AM, Hadriel Kaplan wrote:

My vote would be no - the SSP would just treat it as any other Contact
URI.  Regardless of it being a GRUU or not, though, the SSP would need
to remember the Contact-URI for emergency calls as described in the text
below.  How that happens is up to the SSP. (for example the SP-SSE could
create some equivalent Contact URI that lasts longer than the duration
of a dialog, or it could mint its own local unique self-made GRUU for
that specific received contact URI, or whatever)  

Ultimately the GRUU concept just doesn't work in practice, as far as
I've been able to tell from several attempts to use it in deployments.
It's very brittle/error-prone.

I've tried to document the issues here:

http://tools.ietf.org/html/draft-kaplan-dispatch-gruu-problematic-00

-hadriel

On Apr 3, 2012, at 12:11 AM, Asveren, Tolga wrote:

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/techwg/attachments/20120403/5c0bacb9/attachment-0001.html 