Subject: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP

From: Paul Beaumont <[email-masked]>
Date: Thu, 28 Jul 2011 19:20:31 +0100

All

Apologies, being first time to IETF and its mailing lists, if this is not the right mailing list to post this request to.

There does not appear to be a standardised means using SIP on emergency calls where B-Party Control [aka Manual Hold] to allow the Emergency Service operator to have visibility of the A-Party [who called 999/112/18000*] hook state. This is something that is supported in circuit switched and is intrinsic to Emergency Service bureau processes. To deal with young children playing with the phone, persons dialling hoax calls, persons incapacitated during the call, etc. Today this is done using SS7 ISUP SUSpend [on-hook cleared] and RESume [off-hook reanswer]. One possibility, although not specifically intended for this purpose - it's for ISDN Terminal Portability - is to formalise use of P-Service-Notification of "user-suspended" and "user-resumed" respectively between Service Provider platforms. Currently the mechanism to achieve this capability is not consistent between IP interconnected operators and also even in a SP's own network where interworking between SIP on Inter Machine Trunk and legacy SS7 ISUP InterConnect Trunks.

Please can you advise where I should submit this question or if this is the right forum then whether the above observation is correct and any supplemental information/comments you may have? 

Thanks
Paul Beaumont

* PS I do not know if this would also be true in NA with 911 and for other nations beyond UK

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 28 Jul 2011 14:33:58 -0400

Hi Paul,

This is an concept (not necessarily the mechanism) that I support as it is definitively a requirement for some countries, notable in North America. I'm certain you are referring to the PSTN only by way of example, not implying to replicate how this functionality is implemented.

I do believe that having a STANDARD mechanism will be beneficial to avoid the vendor-specific, non-compatible approaches we have to deal with today.

Guy

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Paul Beaumont
Envoyé : 28 juillet 2011 14:21
À : IETF - ECRIT
Objet : [Ecrit] Emergency Call On-Hook / Off-Hook Indication during Manual Hold Over SIP

All

There does not appear to be a standardised means using SIP on emergency calls where B-Party Control [aka Manual Hold] to allow the Emergency Service operator to have visibility of the A-Party [who called 999/112/18000*] hook state. This is something that is supported in circuit switched and is intrinsic to Emergency Service bureau processes. To deal with young children playing with the phone, persons dialling hoax calls, persons incapacitated during the call, etc. Today this is done using SS7 ISUP SUSpend [on-hook cleared] and RESume [off-hook reanswer]. One possibility, although not specifically intended for this purpose - it's for ISDN Terminal Portability - is to formalise use of P-Service-Notification of "user-suspended" and "user-resumed" respectively between Service Provider platforms. Currently the mechanism to achieve this capability is not consistent between IP interconnected operators and also even in a SP's own network where interworking between SIP on Inter Machin
 e Trunk and legacy SS7 ISUP InterConnect Trunks.

Thanks
Paul Beaumont

* PS I do not know if this would also be true in NA with 911 and for other nations beyond UK
_______________________________________________
Ecrit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ecrit

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 28 Jul 2011 14:40:48 -0400

If I'm following this, you are talking about the ability of the PSAP to control termination of the call, and be able to detect hook state while the call is being held up by the PSAP.

This is a long running discussion.  This requirement is very firm for some members of the work group, but has very strong opposition.  Some of those objecting believe that the mechanism the PSTN uses is inappropriate, and the problem that the PSTN solution addresses is better obtained with user interface changes on IP devices.  Other objectors believe that it should not be possible for the PSAP to hold the call because it may use too many resources in a network, especially a mobile network.

We have had numerous conversations.  We could not converge on a problem statement, requirements or solutions.  

Given the IETF consensus process, I personally don't see a way forward on this requirement, although if there were significantly more participants who came to the conclusion that the requirement is important, and solutions must be found, that could change. There have been discussions of doing this work outside the IETF, but that would violate the SIP change process.  

Brian

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 28 Jul 2011 20:41:58 +0200

I believe this was extensively discussed during the development of this document.

Given the late stage of this document before publication, I think it behoves anyone wanting a change in the document to identify new arguments over and above the prior discussion which took place a long long time ago.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: 28 July 2011 19:34
> To: Paul Beaumont; IETF - ECRIT
> Subject: Re: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during
> Manual Hold Over SIP
> 
> Hi Paul,
> 
> This is an concept (not necessarily the mechanism) that I support as it is
> definitively a requirement for some countries, notable in North America.
> I'm certain you are referring to the PSTN only by way of example, not
> implying to replicate how this functionality is implemented.
> 
> I do believe that having a STANDARD mechanism will be beneficial to avoid
> the vendor-specific, non-compatible approaches we have to deal with today.
> 
> Guy
> 
> Apologies, being first time to IETF and its mailing lists, if this is not
> the right mailing list to post this request to.
> 
> There does not appear to be a standardised means using SIP on emergency
> calls where B-Party Control [aka Manual Hold] to allow the Emergency
> Service operator to have visibility of the A-Party [who called
> 999/112/18000*] hook state. This is something that is supported in circuit
> switched and is intrinsic to Emergency Service bureau processes. To deal
> with young children playing with the phone, persons dialling hoax calls,
> persons incapacitated during the call, etc. Today this is done using SS7
> ISUP SUSpend [on-hook cleared] and RESume [off-hook reanswer]. One
> possibility, although not specifically intended for this purpose - it's
> for ISDN Terminal Portability - is to formalise use of P-Service-
> Notification of "user-suspended" and "user-resumed" respectively between
> Service Provider platforms. Currently the mechanism to achieve this
> capability is not consistent between IP interconnected operators and also
> even in a SP's own network where interworking between SIP on Inter Machin
> Please can you advise where I should submit this question or if this is
> the right forum then whether the above observation is correct and any
> supplemental information/comments you may have?
> 
> Thanks
> Paul Beaumont
>

---

From: Marc Linsner <[email-masked]>
Date: Thu, 28 Jul 2011 14:46:28 -0400

Paul,

Feel free to review the draft submission at:

http://tools.ietf.org/html/draft-rosen-ecrit-premature-disconnect-rqmts-02

You may also find message threads on the topic in the list archives in the
early 2009 timeframe.

-Marc-

-----Original Message-----
From: Paul Beaumont <[email-masked]>
Date: Thu, 28 Jul 2011 19:20:31 +0100
To: IETF - ECRIT <[email-masked]>
Subject: [Ecrit] Emergency Call On-Hook / Off-Hook Indication during
Manual Hold Over SIP

>999/112/18000*] hook state. This is something that is supported in
>circuit switched and is intrinsic to Emergency Service bureau processes.
>To deal with young children playing with the phone, persons dialling hoax
>calls, persons incapacitated during the call, etc. Today this is done
>using SS7 ISUP SUSpend [on-hook cleared] and RESume [off-hook reanswer].
>One possibility, although not specifically intended for this purpose -
>it's for ISDN Terminal Portability - is to formalise use of
>P-Service-Notification of "user-suspended" and "user-resumed"
>respectively between Service Provider platforms. Currently the mechanism
>to achieve this capability is not consistent between IP interconnected
>operators and also even in a SP's own network where interworking between
>SIP on Inter Machin

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 28 Jul 2011 17:38:51 -0600

Paul,

See RFC 3398 Section 9 for SIP in the core network (SIP to ISUP
interworking).  This handles both ISUP terminal portability and
the equivalent POTS-based suspend/resume.  For SIP at the access device,
there is not necessarily a hook-state, but if the UA wants to, it could
use equivalent re-INVITE or UPDATE (RFC 3311) methods.

The value to the PSAP is knowing why there is silence on the line.  A
decent UA should never disconnect a 911 call in the first place, and
there is no need to disconnect the microphone and speakers regardless of
any physical positioning of the handset.  This is something that is
only possible using metallic access in the PSTN.

--brian

On Thu, 28 Jul 2011, Paul Beaumont wrote:

> All
> 
> Apologies, being first time to IETF and its mailing lists, if this is
> not the right mailing list to post this request to.
> 
> There does not appear to be a standardised means using SIP on
> emergency calls where B-Party Control [aka Manual Hold] to allow the
> Emergency Service operator to have visibility of the A-Party [who
> called 999/112/18000*] hook state. This is something that is supported
> in circuit switched and is intrinsic to Emergency Service bureau
> processes. To deal with young children playing with the phone, persons
> dialling hoax calls, persons incapacitated during the call, etc. Today
> this is done using SS7 ISUP SUSpend [on-hook cleared] and RESume
> [off-hook reanswer]. One possibility, although not specifically
> intended for this purpose - it's for ISDN Terminal Portability - is to
> formalise use of P-Service-Notification of "user-suspended" and
> "user-resumed" respectively between Service Provider platforms.
> Currently the mechanism to achieve this capability is not consistent
> between IP interconnected operators and also even in a SP's own
> network where interworking between SIP on Inter Machine Trunk and
> legacy SS7 ISUP InterConnect Trunks.
> 
> Please can you advise where I should submit this question or if this
> is the right forum then whether the above observation is correct and
> any supplemental information/comments you may have? 
> 
> Thanks
> Paul Beaumont
> 

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: Paul Beaumont <[email-masked]>
Date: Fri, 29 Jul 2011 22:22:56 +0100

Hi Guy

Thank you for response. It is good to know that you like me have encountered the issue. As you indicate having a standard mechanism for how this function is implemented, as an adjunct to  RFC3261, that can be cited to vendors and other carriers we interconnect with will remove the current ambiguity.

Yes, as you surmised I am referring to the PSTN. In my case the issue arises both on legacy access, where there is SIP interworking in the network, and NGA, where there are SIP controlled ATA in the homes of users connected via FTTH.

Paul Beaumont

--

---

From: Paul Beaumont <[email-masked]>
Date: Sat, 30 Jul 2011 10:34:57 +0100

Hi Brian

Thank you for your response.

As a result of my posting I am becoming aware of the background and my apologies to the community for not doing more research on this before posting to the list.

However, I do see this as being important and it would appear some others regards it as requiring a solution too. The fact that it keeps getting raised and across both legacy and evolved service platforms affirms this.

I would see any potential RFC as being an adjunct to base RFC3261 SIP. Whether to apply depends on the policy of each network operator. An MNO may choose not to*, based on established precedence and scarcity of radio resource, whilst an FNO may choose to, based on established precedence and compliance of providing primary line telephony. I view the logical SDO body to do this as being IETF; for the reason you state.

Whether the number and profile of the individual supporters/objectors concerned is sufficient to make the prospect of "rough consensus" likely I cannot comment on, being so new to IETF.

Thanks
Paul Beaumont

* With VoLTE being based on SIP there is an opportunity, should they want to, for MNOs to support Called Party Control of the call.

--

---

From: Paul Beaumont <[email-masked]>
Date: Sat, 30 Jul 2011 12:09:22 +0100

Brian

Thank you for the explanation and RFC references. I will go have a read.

Paul

--

---

From: Paul Beaumont <[email-masked]>
Date: Sat, 30 Jul 2011 12:18:07 +0100

Marc

Many thanks for the link to the draft. I will go have a read of it.

Paul

--