Subject: Re: [Sipping] new event package for CCBS, CCNR, MWI

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 26 Jul 2002 12:30:26 +0200

Hello Mark, All
 
to pick up on some of the points:
 
As you could see from our initial mail the main scope of this package would be at the interworking point from SIP to SS7 network. The state "busy" is pretty clear defined in ISDN/PSTN so it gives us the possibility to transfer the information about the change in this state to the SIP end point.
It also was not our intention to use the dialog package, but to define a new similar to the one described in the Message Waiting Indication draft. And definitely an  interworking point in this case has no call state information it is just a mediation node.
 
As of the usefulness of a particular service it is the market decision not the technical group's. 
 
Greeting,
Denis Alexeitsev

_______________________________________________
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: Sat, 27 Jul 2002 03:02:36 -0400

Alexeitsev, D wrote:
> As you could see from our initial mail the main scope of this package
> would be at the interworking point from SIP to SS7 network. The state
> "busy" is pretty clear defined in ISDN/PSTN so it gives us the
> possibility to transfer the information about the change in this state
> to the SIP end point.

SIP is not SS7.

I would *strongly* object to an attempt to standardize an event package 
that is not going to generally work or be applicable in the broader SIP 
context, and would ONLY work in the case where the endpoint is an SS7 
gateway with a more limited definition of busy. That leads to lack of 
interoperability, since a SIP application would need to be built 
differently depending on whether the endpoint is a gateway or normal UA.

As Mark has pointed out, the meaniung of "busy" in the context of a SIP 
UA is not as readily defined as it is in the PSTN. In fact, its far more 
complex than Mark has indicated, since "busy" could be do to a variety 
of fairly complex policies that are executing across one or more proxies.

> It also was not our intention to use the dialog package, but to define a
> new similar to the one described in the Message Waiting Indication
> draft. And definitely an  interworking point in this case has no call
> state information it is just a mediation node.

Well, thats your problem. You are attemtping to get service transparency 
by mapping messages and not the semantic operations implied by them.

When the interworking point receives a subscription to the dialog 
package for a phone on the PSTN, a reasonable interpretation of that 
would be to request the CCBS notification in the PSTN, since its 
actually a good indicator of dialog state there. I don't know whether 
doing that requires maintenance of some kind of state in the gateway 
after the REL is received. If so, than doing so is needed for this to work.

-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

---

From: Al Varney <[email-masked]>
Date: Sat, 27 Jul 2002 07:23:54 -0500

At 03:02 AM 7/27/02 -0400, Jonathan Rosenberg wrote:
>As Mark has pointed out, the meaniung of "busy" in the context of a SIP UA 
>is not as readily defined as it is in the PSTN. In fact, its far more 
>complex than Mark has indicated, since "busy" could be do to a variety of 
>fairly complex policies that are executing across one or more proxies.

    Not to dispute Jonathan's point, but to clarify somewhat:

    "Busy" as a state in the PSTN is also more complex than some might 
realize.  As a state, it is only well-defined for directly-connected (not 
PBX) analog and ISDN lines that are not part of a complex multi-line group 
and do not have terminating IN triggers (where termination attempts lead to 
an IN SCP query, which can redirect call attempts).

    In most other cases, a "busy" REL can be returned to other ISUP nodes, 
including SIP-ISUP gateways, only because it is a event detected by a call 
attempt to the PSTN switch supporting the called number -- but not a 
"state" maintained by that PSTN switch.  (A similar case exists where an IN 
SCP might control the "busy-ness" of a number, such as a Toll-free 
number.)  In such cases where "busy" as a state is not well-known to a 
single PSTN switch, CCBS attempts to such numbers will be rejected by the PSTN.

    If you view proxy-controlled call completion to SIP endpoints as 
similar to call completion to PSTN numbers without a well-defined "busy" 
state, then it's going to require very elaborate mechanisms to make CCBS 
work.  I don't believe SS7 standards bodies even sized the effort to make 
CCBS work in those non-simple cases.

    I don't know if there's an equivalent to a "simple SIP endpoint", where 
it "knows" that it (and not some proxy) is the only place that can 
determine "busy".  If so, then CCBS might be relatively easy to do for that 
endpoint type.  If any other node in SIP can respond with "busy" to a call 
attempt, it becomes very difficult to ensure consistent, fair CCBS operation.

Al Varney