RE: [Sipping-emergency] Call hold

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

Henning,

I can access and download the referenced documents (but can't share them; I
can't even share them with Tom, who must retrieve them himself).  However, I
took a look and this is the detailed information that is described at a high
level for Nortel's product (per that other URL I had sent)  around the SS7
support for the Connection Hold. (For ISDN, it's not possible to prevent the
disconnect, so that's why they need the dialback).  The first line of the
addendum is the deletion of that text in section 6.1.4 referenced in your
initial email below. Are you certain that was from TR.628-2001 (and not
2000) as the one document is the addendum to TR.628-2000 and I couldn't find
a TR.628-2001? 

The addendum also has all the TCAP messaging for the interface to the SRDB. 

Mary.

-----Original Message-----
From: Henning Schulzrinne [mailto:[e-mail]]
Sent: Friday, April 04, 2003 4:07 PM
To: [e-mail]
Subject: [Sipping-emergency] Call hold


Mary Barnes wrote:

 > 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'm not sure it matters. It doesn't seem necessary for a minimal 
implementation of emergency calling that does no more than basic 911 in 
the US/Canada, but that shouldn't keep us from collecting requirements 
that allow services that improve upon the user experience. That's why I 
labeled it a MAY rather than a SHOULD or MUST requirement.

Since our current effort is on a minimal feature set and since we seem 
to agree that this is probably an end system implementation issue rather 
than a protocol requirement as long as the end system can reliably 
detect that an emergency call is in progress, we may be able to defer 
this and move on to the more crucial service aspects.


 >
 > 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 this would be more appropriately addressed in the requirements 
doc. If that's ok, I will add some explanatory text to that section 
reflecting our discussion.

Btw, I dug up the ANSI reference and found another interesting document 
that directly bears on this topic:

http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=577743

http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=557653

Can anybody here get at these documents through some kind of liaison 
relationship? I don't have a spare $238 to buy these documents...

http://www.nssn.org/NssnSearch/DisplayRecord.asp?RecordNo=557182 is also 
relevant.

 >
 > 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?


Given that support is purely predicated on end system behavior, there 
seems little harm in suggesting that implementors take this into 
consideration. My perception is that the IETF has generally tried to 
stay away from "user interface" descriptions, but I won't complain


 >
 > 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.


Also, I think this was motivated since it was difficult to call back the 
original caller. I suspect that in most cases, callers don't make a 
different call, but simply hang up. In that case, ringback is far more 
useful to get the emergency caller back on the line to ascertain that 
the emergency has indeed passed or was a false alarm (or, as seems 
common, that the emergency call button was pressed while the phone was 
in somebody's back pocket).


 >
 > 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.)


I will try to add some motivating text.

 >
 > 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.
 >


_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency
_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency