Subject: Re: [Sipping] Re: Comments on revised 'sos' draft

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 03 Jan 2003 23:10:47 -0500

William Marshall wrote:
> One aspect of 'sos' calls that is rather annoying is that there
> is no agreed standard for some details of the service.  While
> organizations such as NENA and ANSI write various documents, local
> justidictions actually set the requirements as part of CLEC-
> certification (important if you want to get blocks of phone numbers
> from the NANP so PSTN subscribers can call your subscribers).
> 
> Some jurisdictions require "called-party control" on 9-1-1 calls.  Some 
> jurisdictions require PSAP-initiated constant-ring on an attempted hangup.
> (I realize that SIP phones, like cell phones, are under the user's
> control and can be disconnected or powered off and the real usefulness
> of these requirements is dubious; but CLEC-certification is still useful).

Since this comes up again and again, I've asked this question (a while 
ago) on the NENA mailing and nobody (that answered) was able to provide 
any indication that this is still true for E911 today. (It was true for 
the early 911 service where the PSAP was connected directly to the local 
switch.) It was claimed that modern ISDN switches don't provide this 
functionality, either. Maybe you're talking about non-North American 
jurisdictions? Do you have citable evidence on this requirement? Since 
the PSAP tandem and the caller switch may be several 'hops' apart, this 
capability would have to be part of ISUP.

I looked at one of the Telcordia/Bellcore specs for 911 service and it 
doesn't mandate it, either. Since CLECs generally don't (like to) write 
their own switch software, I'd imagine that this would at least be a 
Bellcore requirement.

I got the following two contradictory quotes, among others:

"I can't speak for Call Transfer however Call Waiting and Three Way
Calling are still available to the 9-1-1 caller.  At least it is here
in a DMS environment."

"From my experience, most switches (5ESS, DMX-100, and GTD5EAX) disable
custom calling features for the entire call when calling to N11 services
in a manner similar to when they are establishing a call to another
number.  In other words, the switch deals with the 911 call like when
you are listening to a ringing signal (i.e.  no call waiting, no call
transfer, no 3-way calling, etc.)."

This only requires the originating switch to recognize N11, so that 
seems fairly easy in PSTN land. I suppose one could say that UAs should 
not use REFER.

> 
> There is a basic design decision of whether it is all in the UA, and if 
> not, potentially a standardization issue.
> 
> If the decision is that the UA doesn't really know when it calls an
> emergence service (possibly due to the numerous ways to dial such a 
> service), then there are several areas that would need some agreement.

This probably argues again for a global identifier. Some behavior, like 
call waiting, doesn't really apply in UAs. REFER issued by the UA to the 
PSAP is harmless.

> 
> 1) what is the effect of a BYE request generated by a UAC that is
> rejected by the UAS with a 4xx (e.g. 403-Forbidden)?  Does the UA
> need to wait for the response to the BYE before tossing call state?
> Likewise, call-stateful proxies on the path?  There is, of course,
> a denial-of-service threat here when a non-PSAP rejects a BYE.

Given the many ways that the caller can terminate a call, this seems 
like a second-order problem. Can ISUP refuse a teardown request? What 
happens in that case?

This may be a simple UI issue. Since this is primarily a prevention of 
accidental disconnects, a UA might want to treat the 403 as a "Callee 
doesn't want to hang up. Do you really want to terminate the call?" (The 
rough equivalent of the corresponding Windows Ctrl-Alt-Del behavior...)

> 
> 2) what is the effect of a mid-call INVITE when the instrument is
> in an on-hook state?  Is 180-Ringing an allowable response?

You mean for PSAP initiated call-back? This would be the same situation 
as if I had sent a BYE and an INVITE crossed on the wire. It would 
probably yield an invalid call-ID error.

> 
> I believe both case are "under-specified" in rfc3261, so the needed
> behavior is allowed but not mandated.  I think this is more than a BCP.

Since these are corner-cases, it seems a bad idea to rely on specific UA 
behavior. Do cell phones support any of the features you describe?

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 05 Jan 2003 22:41:29 -0500

inline.

> like a second-order problem. Can ISUP refuse a teardown request? What 

SIP does in fact describe behavior here. According to Section 15.1.1:

The UAC MUST
    consider the session terminated (and therefore stop sending or
    listening for media) as soon as the BYE request is passed to the
    client transaction.

Thus, rejecting the call will not achieve the "desired" effect.

> probably yield an invalid call-ID error.

THis re-INVITE would appear to the UA as a new INVITE (not corresponding 
to an existing dialog) but with tags. Behavior in this case is also well 
specified in 3261. Section 13.3.1 bullet 3 covers this case, and it 
refers the reader to Section 12.2.2. That section says that, unless you 
are specifically re-creating old dialogs beacuse you are a conferencing 
server or something, then you should send a 481.

>> behavior is allowed but not mandated.  I think this is more than a BCP.

It is most certainly not "under-specified".

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com