[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sipping] re: comments on cc-framework
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
frank.derks@philips.com@ietf.org on 05/02/2002 03:55:53 AM
Sent by: sipping-admin@ietf.org
To: Rohan Mahy <rohan@cisco.com>
cc: mpierce1@aol.com, sipping@ietf.org, sipping-admin@ietf.org
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
<rohan@cisco.com> To:
Sent by: mpierce1@aol.com
sipping-admin@ietf.org cc:
sipping@ietf.org
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: sipping@ietf.org
Subject: [Sipping] Comments on draft-cc-framework
From: Mpierce1@aol.com
Date: Fri, 26 Apr 2002 15:42:14 EDT
List-Id: SIPPING Working Group (applications of SIP) <sipping.ietf.org>
Sender: sipping-admin@ietf.org
--------------------------------------------------------------------------------
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 sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP