Subject: Re: [Sipping] re: comments on cc-framework

From: [email-masked]
Date: Fri, 3 May 2002 13:57:39 +0200

Tom,

I would say that it is a bit "steep" to state that the PBX feature set
is not applicable to the world of IP telephony. In reality it is, 
otherwise
there would be no motivation for people to switch from one world to the
other. 

Today's reality is that VoIP offers a subset of the traditional telephony 
world and close to nothing of all those features that might be possible 
because the infrastructure is IP and different protocols are being used.
Apparently this subset is sufficient for some to switch, but not for all.
Furthermore, the decision to switch to VoIP is largely based on the 
availability of certain traditional features. 

Possibly, SIP is not striving for feature transparancy (which I define as
all involved parties knowing enough about what's going on so they can make
"informed" decisions), but in order to have features work across a network 

of distributed intelligent endpoints, sufficient information needs to be 
disseminated. I.e. end-end customisation and personalisation (can you 
please define exactly what end-end customisation and end-end 
personalisation are) require careful thinking of what needs to be 
exchanged. Local policy control certainly does not answer this question.

Regards,

Frank

SIP is not aiming for feature transparency as DPNSS does. Instead it is a
protocol that can be used to carry enough information so that end points
can operate under local policy control. SIP aims to create a system in
which features can be customised and personalised end-to-end. This is
completely different from the traditional PBX model in which features are
defined and maintained centrally.

Indeed the tradtional PBX featre set is not relavent to the world of IP
telephony.

Thanks

Tom Gray

[email-masked]@ietf.org on 05/02/2002 03:55:53 AM

Sent by:  [email-masked]

To:   Rohan Mahy <[email-masked]>
cc:   [email-masked], [email-masked], [email-masked]
Subject:  Re: [Sipping] re: comments on cc-framework

Rohan,

your disagreement on "needing to know exactly what's going" on, seems
to stem from experience with "dozens of features" that are typically
used on "dumb" terminals on intelligent, centralised systems (e.g. a
PBX). In those cases it is normally true that the terminal does not
need to know a lot about what's going on. Typically it is sufficient
to simply instruct it to put something on the display and/or to switch
some LED(s) on or off. Unfortunately (or fortunately?), this is the
realm of protocols like MGCP/Megaco/(Euro)Packetcable, etc. So, if
this is all that SIP is going to bring, why should I use it?

I usually try to compare the use of protocols like SIP (and H.323)
with the use of protocols like QSIG, DPNSS and the likes. These
protocols are an attempt to create distributed systems by linking
systems in such way that much of the information that is known by
one system is also known by the other system(s) involved in a call.

If what you're proposing were true, it would not be necessary to
have these complicated networking protocols to have "linked"
systems appear as one.

The real complication here is that it is difficult to determine which
information needs to be shared. In practice (as demonstrated by the
protocols that I mentioned), this is service dependent.

Regards,

Frank

                           Rohan Mahy  
                           <[email-masked]>                To:  
                           Sent by:                 [email-masked]  
                           [email-masked]           cc:  
                                                    [email-masked]  
                           29-04-2002 06:32 PM      (bcc: Frank  
                                                    Derks/HVS/BE/PHILIPS)  

                                                            Subject:  
                                                    [Sipping] re: comments 
 
                                                    on cc-framework  

Classification: 

Hi,

I haven't received enough comments to warrant an update to the draft at
this point.  I am planning to incorporate almost all of Mike's comments. I
would like to reply to one of Mike's comments here however.

----
4.7 This statement that "only the invoker[s] of features in SIP know
exactly which feature they are invoking" sounds good in theory, but the
reality for telephony services is that often both parties (devices) need
to explicitly know what service is being performed, not just what
signaling primitives are being used. It is clear, for example, that the
processing of an INVITE or a REFER depends on the reason it was sent,
whether it is a new call or a transfer or a barge in, etc.

Rohan> I disagree.  I have run through dozens of features which use these
Rohan> features and I have never had this problem.  I suppose I can't
Rohan> expect you and others to just take my word on faith so I will try
Rohan> to come up with some more convincing examples.  Please feel free
Rohan> to come up with a counter-example.

The example of Alice calling Bob who transfers to Carol, while Alice has
her robotic assistant Alice "conferenced" illustrates this. First, the
independence of these two separate "features" would not be compromised if
the message from Bob to Alice explicitly said "transfer" rather than the
generic "REFER".

Rohan> I'm not convinced, but assuming you are correct, what benefit would
Rohan> this have?

Secondly, one should assume that the interaction between
the "robotic" feature at Alice with transfer (caused by receipt of the
REFER) might have to be different than the interaction between this
"robotic feature" and other features caused by receipt of REFER.

Rohan> Why?

When this
happens, attempts will have to be made at the receiving end (Ann) to
deduce what was intended in order to figure out what the best course of
action is to provide a good service.

Rohan> I disagree.  The basis for the model is that the sender asks the
Rohan> receiver to invoke a well-defined primitive.  The receiver can use
Rohan> very simple rules to figure out whether to authorize whole
Rohan> categories of requests or not.  The sender is free to use these
Rohan> primitives for whatever service they can invoke with the primitives
Rohan> at hand.

thanks,
-rohan

------------

To: [email-masked]
Subject: [Sipping] Comments on draft-cc-framework
From: [email-masked]
Date: Fri, 26 Apr 2002 15:42:14 EDT
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
Sender: [email-masked]

--------------------------------------------------------------------------------
To all,

I submitted comments on draft-ietf-sipping-cc-framework-00 (Feb) before
the March meeting, but have seen no responses or other comments. I will
repeat these comments with some others added:

3.1 Final bullet item: It isn't clear what point is being made about the
model from H.450.  While the goal says "do not reinvent", the rest of the
statement seems to say that SIP will not use an existing model, but rather
reinvent it.

4.1.1 This section notes that existing terms "call" and "conference" are
not well defined, so it uses a new term "conversation space". While this
concept seems useful, it is not well defined either. The statement that it
is "essentially a set of participants who believe they are all
communicating among one another" is not precise enough.

4.5.2 Reference to serving the queue should refer to "the first call in
the relevant queue" not the "last".

5.2.2 The statement that "there is no way to distinguish between the
desire to go on or off hold" is interesting. Is this meant to say that the
REFER method mentioned won't work for this and some better method is
needed?

5.3 1 Since B apparently has to do something before C replaces A, the
description of this primitive should be: "A requests to be replaced with
C"

5.3.2 Since B has to do something with the INVITE (stop sending media to
C, start using media from A rather than C, etc) this really isn't "A
forcibly replacing C with itself". It's really still just a request from A
for B to replace C with A.

The note regarding the need to take different action depending on the
state of the receiving entity "B", refers to a problem that affects many
of the primitives described. Because of overlapping actions, practically
every action at the receiving entity needs to consider the state of the
receiver before taking the described action. However, the model for this
work seems to be that the sender decides the action required and the
receiver must do it.

5.3.5 As above, this is just a "request" by A to be inserted into an
existing space. B must actually do it upon receipt of the INVITE, meaning
that B can refuse (as implied by the phrase "if B accepted the
INVITE..."). Therefore, the statement should be:

A requests to be inserted into a conversation space.

5.3.6 should have a statement added after the depiction of the change of
conversation space that says what is happening. It appears to be the
following:

A causes conversation space to be split into two with itself and B making
up the new conversation space.

5.3.7 It is not clear from the diagram and statement before it what has
happened. It should say:

The conversation space changes like this:
( A , B ) --> (B , A ) & ( A , C )
A creates a new conversation space with C and participates in both as the
"anchor".

Mike Pierce
Artel

_______________________________________________
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: Henry Sinnreich <[email-masked]>
Date: Sun, 05 May 2002 10:51:43 -0500

>is not applicable to the world of IP telephony.

It is not, here is why the PBX feature set is old junk IMHO:

Because SIP changes most assumptions about the PBXs/Class 5/Softswitch

* Enterprise communications w. SIP/mobility for all networks and devices

* Parallel voice and IM/e-mail communications: Attended transfer and
consultation hold may use IM as an parallel communication channel,

* Use presence attributes for polite calls,

* Use presence for call-back,

* Use presence to set up ad-hoc conferences,

* Use presence instead of ACD for call center agents,

* Use PC with GUIs as the personal communications manager,

* Attendant work station becomes a SIP PC telephony device,

* Voice mail becomes a component of unified messaging, 

* Include cordless/mobile phones and PDAs,

* Integrate video and data collaboration.

Henry
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, May 03, 2002 6:58 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sipping] re: comments on cc-framework

Tom, 

Today's reality is that VoIP offers a subset of the traditional
telephony 
world and close to nothing of all those features that might be possible 
because the infrastructure is IP and different protocols are being used.

Apparently this subset is sufficient for some to switch, but not for
all. 
Furthermore, the decision to switch to VoIP is largely based on the 
availability of certain traditional features. 

Possibly, SIP is not striving for feature transparancy (which I define
as 
all involved parties knowing enough about what's going on so they can
make 
"informed" decisions), but in order to have features work across a
network 
of distributed intelligent endpoints, sufficient information needs to be

Regards, 

Frank 

SIP is not aiming for feature transparency as DPNSS does. Instead it is
a
protocol that can be used to carry enough information so that end points
can operate under local policy control. SIP aims to create a system in
which features can be customised and personalised end-to-end. This is
completely different from the traditional PBX model in which features
are
defined and maintained centrally.

Thanks

Tom Gray

Rohan,

Regards,

Frank

                          Rohan Mahy

                          <[email-masked]>                To:

                                                   [email-masked]

                                                   Derks/HVS/BE/PHILIPS)

                                                           Subject:

                                                   [Sipping] re:
comments  
                                                   on cc-framework

Classification: 

Hi,

I haven't received enough comments to warrant an update to the draft at
this point.  I am planning to incorporate almost all of Mike's comments.
I
would like to reply to one of Mike's comments here however.

----

Rohan> I disagree.  I have run through dozens of features which use
these

The example of Alice calling Bob who transfers to Carol, while Alice has
her robotic assistant Alice "conferenced" illustrates this. First, the
independence of these two separate "features" would not be compromised
if
the message from Bob to Alice explicitly said "transfer" rather than the
generic "REFER". 

Rohan> I'm not convinced, but assuming you are correct, what benefit
would
Rohan> this have?

Rohan> Why?

When this

Rohan> I disagree.  The basis for the model is that the sender asks the
Rohan> receiver to invoke a well-defined primitive.  The receiver can
use
Rohan> very simple rules to figure out whether to authorize whole
Rohan> categories of requests or not.  The sender is free to use these
Rohan> primitives for whatever service they can invoke with the
primitives
Rohan> at hand.

thanks,
-rohan

------------

To: [email-masked]

------------------------------------------------------------------------
--------
To all,

3.1 Final bullet item: It isn't clear what point is being made about the
model from H.450.  While the goal says "do not reinvent", the rest of
the
statement seems to say that SIP will not use an existing model, but
rather
reinvent it.

concept seems useful, it is not well defined either. The statement that
it

5.2.2 The statement that "there is no way to distinguish between the
desire to go on or off hold" is interesting. Is this meant to say that
the
REFER method mentioned won't work for this and some better method is
needed?

5.3.2 Since B has to do something with the INVITE (stop sending media to
C, start using media from A rather than C, etc) this really isn't "A
forcibly replacing C with itself". It's really still just a request from
A
for B to replace C with A.

5.3.5 As above, this is just a "request" by A to be inserted into an
existing space. B must actually do it upon receipt of the INVITE,
meaning
that B can refuse (as implied by the phrase "if B accepted the
INVITE..."). Therefore, the statement should be:

A causes conversation space to be split into two with itself and B
making
up the new conversation space.

The conversation space changes like this:
( A , B ) --> (B , A ) & ( A , C )
A creates a new conversation space with C and participates in both as
the
"anchor".

Mike Pierce
Artel