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

[Asveren, Tolga]

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/20120402/0e6ba7dd/attachment.html