[Sipping-emergency] FW: Connection Hold (was RE: Report on sipemergency call

["Mary Barnes" <[e-mail]>]

This just bounced (I don't know if Henning's originally post made it to the
list either...)

-----Original Message-----
From: Barnes, Mary [NGC:B602:EXCH] 
Sent: Friday, April 04, 2003 3:37 PM
To: 'Henning Schulzrinne'
Cc: [e-mail]
Subject: Connection Hold (was RE: Report on sipemergency call


Henning,

By "punting" are you proposing to remove some of the text from your
requirement S2 (i.e the "MAY make it more difficult to disconnect")?    

I fully agree that this would likely be solved by an end-system as described
in S2.  However, I think since this topic gets brought up every time SIP and
emergency calls have been discussed (at least the discussions I've heard
over the past 2+ years). [Just as the early media continues on and on, I can
see this one following a similar path unless we address it upfront.]  

I think one reason debate of this topic seems to keep recurring is that it
appears to be an easy target highlighting that a SIP network can't meet the
expectations that some folks have in terms of equivalent functionality that
they feel they have in the PSTN.  Just playing devil's advocate, one could
suggest that the only reason the functionality is optional in today's
networks is that the value it brought wasn't worth the deployment impact of
ensuring that all the network components in the PSTN could support it.  And,
following on this, the argument might be that since we're building SIP from
scratch, why can't we make sure it gets considered and engineered in from
the beginning? 

I think what we need to do is understand why this optional functionality was
considered desireable (i.e. why was it an underlying requirement) and
resolve that either the condition in the PSTN under which this functionality
was desireable doesn't apply to SIP or address what the fundamental
requirement is in terms of SIP.  I think you've addressed the equivalent
implied functional requirement in terms of SIP.  But, I think it's worth
considering why they even had that requirement in the PSTN and if it's even
still needed in SIP.  

In terms of PSTN emergency calls, this functionality was highly desireable
because that physical phone line is the only communication path and
potential means of identifying the person making the call.  However, we all
know that SIP is different because you have multiple methods of
communication and of course this is stated up front in Henning's current
requirements document and clearly stated upfront in section 2, so I'm not
proposing any new requirements. 

I agree for the audience on this list that the requirements are fine, but
perhaps the requirements document needs to be absolutely blunt that there
may appear to be equivalent functionality that isn't provided by these
requirements, however, here's some examples of such things and explicitly
explain why they don't map to a hard and fast requirement for SIP.   So,
perhaps what I'm proposing either expanding section 2 with a bit more
background or an appendix for now that gives the background on this and
states why this is only a MAY requirement (i.e the SIP paradigm provides
additional information via other means such that the calling voice line is
not the only means for getting information about the caller so it's not
deemed imperative that the "connection" remains active, although one could
enforce this at an intelligent endpoint.)  

Mary. 

-----Original Message-----
From: Henning Schulzrinne [mailto:[e-mail]]
Sent: Thursday, April 03, 2003 5:59 PM
To: Barnes, Mary [NGC:B602:EXCH]
Cc: [e-mail]
Subject: Re: Report on sipemergency call


 From some of my notes (sorry, original source lost). In any event, 
doesn't contradict the earlier discussion, just probably indicates that 
this is a requirement we can punt on for now. (In any event, I don't see 
how this can be anything but an end-system feature. Knowing that a call 
is an emergency call is crucial to implementing any such end system 
services, so that's why the requirements document calls this out.)

Reverse reachability is much more important, in my opinion.


The full document (ANSI T1.628-2001) states:

-------------------------------
4.1.4   E9-1-1 Call Hold

E9-1-1 Call hold is an optional network feature provided to a PSAP which
prevents a caller from disconnecting an ESC.  Capabilities needed for
supporting E9-1-1 Call Hold are described in Clauses 4 and 5.  However,
there is no DSS1 or SS7 support for this capability at this time.
-------------------------------

Both documents clearly state that CALL HOLD can not be universally
supported, in fact it is clearly stated that a network reconnect - i.e.
call back will be attempted only - this is because the network may not
have the actual callers station ID, but some other number, reflecting
maybe the billing number or a location based "equivalent number" in the
case of larger organizations.  The fact that SS7 does not support this
provision will effect the ability of call hold via Tandem Offices as is
the case with most E911 offerings.