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

[Hadriel Kaplan]

One more nit - you said "globally routable Contact", but I assume you just mean a Contact resolvable by the Service Provider to reach the same UA/line through the SIPconnect path.  The PSAP needs to get a Contact it can generate an out-of-dialog request to, and reach the ultimate UA with it, but in many deployments the PSAP would not get the same literal string Contact URI generated by the Enterprise/SIP-PBX, but rather a Contact URI generated by the SIP Service Provider which it (the provider) can later route to the SIP-PBX and become the same Contact the PBX gave originally.

The tricky thing is in SIPconnect we don't specify what happens inside the service provider, so I think just describing it as an Enterprise Contact URI that can later be used in an out-of-dialog request to reach the same UA/line should suffice.
Is that OK?

-hadriel


On Apr 2, 2012, at 9:46 AM, Hadriel Kaplan wrote:


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>


_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org<mailto:techwg at sipforum.org>
Unsubscribe or edit options at:  http://sipforum.org/mailman/listinfo/techwg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/sipconnectit/attachments/20120402/929d429c/attachment.html