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

[Bharrat, Shaun]

I seem to recall there was some disagreement about how the SIP-PBX
should handle

this wrt whether it applies to future requests and, if so, how long. The
MUST NOT 

was probably to sidestep this. Just a really vague recollection though
so take with

a grain of salt...

 

Cheers,

Shaun

 

 

From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org]
On Behalf Of Hadriel Kaplan
Sent: Sunday, April 01, 2012 2:41 PM
To: techwg at sipforum.org
Cc: sipconnectit at sipforum.org
Subject: Re: [SIPForum-techwg] SIPconnect v1.1 changes for emergency
services

 

 

One other, unrelated topic:
When I made the v1.1b changes, I noticed that section 15.4.1.2 states:
"The SP-SSE MUST NOT issue a 302 Moved Temporarily redirect response to
a REGISTER request, to get the SIP-PBX to Register with an alternate
SP-SSE address identified by the Contact URI in the response."

That's an odd thing to have a MUST NOT for.  Does anyone remember why we
have that section say that?

-hadriel

 

 

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
Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20120409/c633d498/attachment.html