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

[Brian Rosen]

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/sipconnectit/attachments/20120403/10998cfe/attachment-0001.html