Subject: [BLISS] BLISS problem statement draft

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 02 Jul 2007 18:31:15 -0400

I've submitted a draft that provides a problem statement around what 
BLISS is trying to solve, and defines a framework for solving it. It 
uses concrete examples the whole way through so we can be clear on what 
we are talking about. Until it appears in the archives, you can pick it 
up here:

http://www.jdrosen.net/papers/draft-rosenberg-bliss-problem-statement-00.txt

This is something I should have gotten out a month or so back, so that 
we could have used it as a context for discussion and draft writing in 
the remaining time. I apologize for getting this in just before the 
deadline - too late to be useful for anyone elses drafts.

I think its really important that we discuss this draft and get 
agreement on it. Its really trying to define the process by which we 
will be doing our work.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 3 Jul 2007 17:01:24 -0500

Hi Jonathan,

Thanks for putting this together. A few comments though:

A few comments on the CFNA example approaches. I know that you aren't
trying to write a document to address CFNA, but since this document
describes a template approach to for documenting features within BLISS I
think it's important that the examples here reflect the type of
discussion that we are looking for in the eventual BLISS RFCs.

Section 3-3.1.3:

- Although approach I could be used for CFNA, the fact that UA Y
returned a 302 means that this could also be used to implement CFU as
well (especially from the proxy's point of view). Essentially, you could
have approach I and II or I and IV running concurrently for the same or
different purposes where the text makes it sound like these are always
discrete cases.

- Figure 3 and 4 are the same but the scenarios are not. Figure 4 needs
to be updated to reflect the text in section 3.1.3.

- Section 3.1.4 seems more like a refinement on section 3.1.2 than a
different approach from the standpoint of the CFNA behavior when the
call is placed by UA X. Configuration of elements would seem to be out
of scope would it not? Otherwise why would we not also consider variants
of how UA Y came to know to forward the INVITE via 302 or proxy mode
(approach I and III respectively)...it seems like it could be endless
without a clear constraint. Another point to consider is that the web
page in approach II could have configured the proxy via CPL as well, or
the CPL in approach IV could have been delivered via SOAP to a web
interface that dumped it into a common database with the proxy. Even
though message 1 in approach IV is SIP, it's not limited to SIP, etc.,
and perhaps we should leave configuration out of scope initially, etc.

Hopefully you see where I'm going with this: we need some sort of
constraint here to limit discussion to something reasonable. 

- Section 3.1.5.1 I'm not sure that assume is the best word here. People
assume things, not machines. The user for UA Y should clearly not expect
their calls to be forwarded to anywhere if they (or an administrator)
never instructed any component of the system to take some sort of action
on their behalf. If nobody implements a feature there can be no
interoperability, and without interoperability there can be no failure
to interoperate. Right?

- Section 3.1.5.2 Again, I think we would need to show the cases where
this isn't user error. If the user went off and told the proxy to
forward their calls after X rings, and then told their UA to do the same
then this is clearly (to me) out of scope for a BLISS feature
discussion. The protocol is working fine, the features are working fine,
nothing is failing here except the user's understanding of the system or
their memory as to what they have told the system to do. 

In a general, I believe you are going to commonly find systems that
(again using CFNA as the example here) offer a feature both at the
network and at the device to ensure that the feature is available for
all users. I don't think race conditions that arise due to duplicated
features is de facto an issue that should be in scope (i.e. user
behavior cannot be specified) unless they interact with each other in
such a way that neither implmentation will work correctly if only one
source for the feature is active at any given point in time. I know you
talk about this more in section 5, but it sounds like we're looking to
find the "best" way of implementing a feature where that widely results
in one way. When a feature such as CFNA is "single-ended", meaning that
there are no requirements on one of the two users involved in the
feature, then having more than one way of doing something is likely to
not cause an issue. If the feature is "double-ended", meaning that there
are requirements placed not only on the device invoking the feature but
the devices that the feature is managing as a result then you run into
issues with having many ways to do the same thing. I believe this is a
nuance that should be captured.

- Section 3.1.5.3 This is a better argument for why some configuration
may matter except that CPL could be delivered to the proxy by some other
source. Essentially it's not the specific mechanism that's being used to
configure the feature, but that there does not exist a means to enable
the feature due to an implied interoperability requirement. 

In general, I would expect most feature vendors to supply you with an
alternative way to configure their features without requiring action on
the client, but perhaps this needs to be stated more directly somewhere.
Maybe include this implied configurability problem in section 5 somehow?

- Section 4 "Allow Variability in Implementation" / "Support a
Multiplicity - I know you probably meant it in the text, but I'd like to
include it explicitly: wireless. The reason I believe this needs to be
stated directly is because it's an environment where the links to the
clients are much more unreliable than in most other environments,
therefore, relying upon the client to take actions may not be feasible
in all cases and more than one approach needs to be accounted for in the
'decision making process' within the Allow Variability in Implementation
section. For instance, approach I does not work reliably in an
environment where the client is not always-on and always-reachable.

- I know ICE solves a number of issues, but you might want to update
your XML template if you should create a -01 version of this document.
:)

Thanks again for putting a document together to review.

Regards,
Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, July 02, 2007 5:31 PM
> To: [email-masked]
> Subject: [BLISS] BLISS problem statement draft
> 
> I've submitted a draft that provides a problem statement 
> around what BLISS is trying to solve, and defines a framework 
> for solving it. It uses concrete examples the whole way 
> through so we can be clear on what we are talking about. 
> Until it appears in the archives, you can pick it up here:
> 
> This is something I should have gotten out a month or so 
> back, so that we could have used it as a context for 
> discussion and draft writing in the remaining time. I 
> apologize for getting this in just before the deadline - too 
> late to be useful for anyone elses drafts.
> 
> I think its really important that we discuss this draft and 
> get agreement on it. Its really trying to define the process 
> by which we will be doing our work.
> 
> Thanks,
> Jonathan R.
> --

---

From: "Gaurav Kheterpal" <[email-masked]>
Date: Thu, 5 Jul 2007 18:16:32 +0530

Jonathan,

My comments below:-

================
Typos/ Grammar
================

* Section 2, 1st Paragraph - should probably include the phrase (consisting
of/comprising of/having)

SIP is typically deployed in environments CONSISTING OF/COMPRISING OF/
HAVING a large number of user agents and some number of servers, such as
proxy servers, registrars, feature servers, and so on

* Section 2, 1st Paragraph - 'unpredicable' was probably meant to be
'unpredictable'

* 3.1.2 - Replace 'arives' with "arrives" & 'ansers' with "answers"

* 5.2 - Replace 'THis' with "This"

* 5.4 - Replace 'interopreability' with "interoperability" & 'neccesary'
with "necessary"

==============
Functional
==============

* 3.1.1 - First Paragraph - You might want to add information to indicate
that the call forward timeout is user configurable/ dependent on the UA & is
not mandated by the protocol itself.

* 3.1.2 - Same comment as above (configurable/dependent on proxy)

* 3.1.3 - Figure 4 is incorrect (probably a copy-paste error from Figure 3)
& needs to be updated.

My 2 cents,
Gaurav

> Sent: Tuesday, July 03, 2007 4:01 AM
> To: [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 05 Jul 2007 09:52:37 -0400

inline.

> different purposes where the text makes it sound like these are always

I thought it important to try and articulate what the problem is that we 
are trying to solve. Thus, it makes sense to take even the simplest 
feature, and demonstrate that, just for CFNA, look how there are 
multiple ways you can implement this, and so there are still interop 
problems.

The discussion wasn't meant to imply that, if you chose one approach for 
one feature, you had to implement that approach for other features. Can 
you point to specific text that led you to this conclusion?

> to be updated to reflect the text in section 3.1.3.

Yes, fixed.

> call is placed by UA X.

Actually its quite different from an interop point of view. I was taking 
the view of "I buy phone from vendor A, proxy from vendor B. Plug them 
together. DOes it work?". In 3.1.4, the failure is due to failure to 
support CPL on one side or another.

> Configuration of elements would seem to be out
> of scope would it not? 

Generally yes; but its part of the overall interop story. This is 
particularly true for things like CPL which blend protocol and config. 
Also true for cases where people want to change configurations of 
features on their UA, without web interfaces. For example, hit the DND 
button on my phone. If DND is executed in the proxy, there needs to be 
signaling from the phone to the proxy to convey that. This kind of 
'feature activation' is kind-of configuration, but is very much in scope 
of our activity. The reason is, if one side does some particular 
approach for it (e.g., XCAP) and the proxy does a different one (HTTP 
POST with some special URI format, or INFO (blech), or whatever...), we 
have an interop failure.

Otherwise why would we not also consider variants
> (approach I and III respectively).

In cases where the configuration is by administrator or user through a 
web page or some tool, and that tool is part of the server that 
implements the feature, I think we don't need to say anything about it. 
But when configuration is to take place on one component, and needs to 
be conveyed in an automated way to another, where the feature is 
implemented, I think we need to talk about it.

..it seems like it could be endless
> without a clear constraint. 

I think our scope covers whatever it needs to cover in order to achieve 
interoperability.

> Another point to consider is that the web

See above.

> interoperability, and without interoperability there can be no failure

I'm not sure I see your point. THe problem is that when an administrator 
buys a proxy from vendor 1 and a UA from vendor 2, when he puts those 
together, CFNA (as an example) will not work. Do you disagree?

> their memory as to what they have told the system to do. 

I think this is a case where user error is easily possible. But I agree 
this scenario here is one of user error, whereas in 3.1.5.1, it is not.

> source for the feature is active at any given point in time. 

I very much want to enable multiple places where a feature can be 
implemented. However I want to make sure that, (1) no matter what 
vendors you bring together, there is a configuration that works, and (2) 
in cases where things can happen in multiple places, we've worked 
through it and taken care of any race conditions or inconsistencies that 
would otherwise happen. In some cases, for example, I can imagine 
needing some kind of capability discovery so that, for example, a proxy 
can know, "hey, that UA can do call forwarding, so I should not bother 
running the timer".

For our analysis of the problems (phase III in the BLISS process) I 
think we should look at everything and then have the discussion we are 
having right now - to determine whether there is a problem here to 
address, or not. That is the whole point of this exercise.

I know you
> not cause an issue.

Usually yes. Single-ended features are great for this case. But even 
then you can have problems.

  If the feature is "double-ended", meaning that there
> nuance that should be captured.

Yes, this is a good point. I'll try to capture that. Per above, "single 
ended" needs to take into consideration the configuration of those 
features. Since if a feature is configured in place X but executed in 
place Y, well its not really single-ended anymore.

> source. 

Sure. But in this case if it comes from the phone the system doesn't 
work. This is exactly my point about why configuration can matter.

> Essentially it's not the specific mechanism that's being used to

Well the problem today is that people in practice, I think, are using a 
lot of different ways to convey feature configuration from UA to proxies 
(when proxies implement the feature). XCAP, CPL, INFO, SOAP, POST, 
SERVICE, etc. Mostly all proprietary. That in itself indicates a problem.

> Maybe include this implied configurability problem in section 5 somehow?

Configuration can be single or double ended also. A single-ended config 
is where the user interacts directly with the component in which the 
configuration needs to reside. Examples: a web page on a proxy for 
configuring call forward, where the call forwarding happens in the 
proxy. In such a case, there is clearly no need to define what the 
interface looks like, in any way.

However, a double-ended config are things like:

  * user enables DND on their phone but this executes in the proxy
  * user utilizes a UI on their phone to set up a call-forward based on 
time of day, and uploads result to the proxy via CPL
  * user configures a custom ringtone from a web page on their proxy, 
and ringtone gets downloaded to phone and executed there

> environment where the client is not always-on and always-reachable.

OK, I will add.

> your XML template if you should create a -01 version of this document.

I've gotten half dozen private mails on this one already. Copy-paste 
error on XML templates.

Thanks,
Jonathan R.

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 9 Jul 2007 15:10:37 -0500

Inline. 

> Sent: Thursday, July 05, 2007 8:53 AM
> To: Stucker, Brian (RICH1:AR00)
> Cc: [email-masked]
> Subject: Re: [BLISS] BLISS problem statement draft
> 
[snip]

> > describes a template approach to for documenting features 
> within BLISS 
> > I think it's important that the examples here reflect the type of 
> > well (especially from the proxy's point of view). Essentially, you 
> > could have approach I and II or I and IV running 
> concurrently for the 
> > same or different purposes where the text makes it sound like these 
> > are always discrete cases.
> 
> I thought it important to try and articulate what the problem 
> is that we are trying to solve. Thus, it makes sense to take 
> even the simplest feature, and demonstrate that, just for 
> CFNA, look how there are multiple ways you can implement 
> this, and so there are still interop problems.
> 

Agree.

> The discussion wasn't meant to imply that, if you chose one 
> approach for one feature, you had to implement that approach 
> for other features. Can you point to specific text that led 
> you to this conclusion?
 
The last paragraph of section 2 makes it sound like this is the case:

   If we consider a particular feature, the protocol machinery for
   accomplishing the feature requires logic on each node involved in the
   feature.  Let us say that feature X can be implemented using two
   different techniques - X.1 and X.2.  Each technique is composed of a
   series of message exchanges and associated state machine processing
   in each affected node.  If all affected nodes implement the same
   logic - say the logic for X.1 - the feature works.  Similarly, if all
   implement the logic for X.2, the feature works.  However, if some of
   the nodes implement the logic for X.1, and others have implemented
   the logic for X.2, the outcome is unpredicable and the feature may
   not interoperate.

I understand what you're trying to say here is within the context of a
single state-machine, and is very likely to be true the more complex the
state machine. However, the example you use in section 3, CFNA, has
several possible implementations that require no synchronization between
nodes to work properly (i.e. it's a single-ended feature). The text from
section 2 relates better to features such as call pickup where you might
be using a dialog event package to know what the state of a call
somewhere else is, etc. The use of the term "approach" and some of the
related text also may not be clear that what you're trying to show are
usecases, and not necessarily discrete implementations of call
forwarding.

Also, not to be nit-picky, but you might say "may be unpredictable"
instead of saying it's always unpredictable. Depending upon the nature
of the interop failure the feature may still work partially or in
specific, enumerable, circumstances. Also, total failure (nothing
happens) is undesirable, but very predictable.

> > 
> > - Figure 3 and 4 are the same but the scenarios are not. Figure 4 
> > needs to be updated to reflect the text in section 3.1.3.
> 
> Yes, fixed.
> 
> > 
> Actually its quite different from an interop point of view. I 
> was taking the view of "I buy phone from vendor A, proxy from 
> vendor B. Plug them together. DOes it work?". In 3.1.4, the 
> failure is due to failure to support CPL on one side or another.

I would agree if configuration is in scope, which you seem to be arguing
for. However, from a "what happens when the INVITE comes in at a
protocol level" there's no difference. This brings up another potential
question that I'm not sure is fully answered in the charter: are the
nodes in these diagrams considered to be black-box, grey-box, or
white-box? I'm taking the black-box view with my statement here, but
perhaps you are intending to make these white-boxes in the
specifications? This could become very contentious later on as people
try to reconcile implementations so we should probably state this
explicitly somewhere what the expectation is.

> 
> > Configuration of elements would seem to be out of scope 
> would it not?
> 
> Generally yes; but its part of the overall interop story. 
> This is particularly true for things like CPL which blend 
> protocol and config. 
> Also true for cases where people want to change 
> configurations of features on their UA, without web 
> interfaces. For example, hit the DND button on my phone. If 
> DND is executed in the proxy, there needs to be signaling 
> from the phone to the proxy to convey that. This kind of 
> 'feature activation' is kind-of configuration, but is very 
> much in scope of our activity. The reason is, if one side 
> does some particular approach for it (e.g., XCAP) and the 
> proxy does a different one (HTTP POST with some special URI 
> format, or INFO (blech), or whatever...), we have an interop failure.

Understand, but I think it would be good to limit ourselves to one
protocol at a time if possible so we can focus discussion. Do we really
want to be in the business of telling people that we expect them to use
XYZ to configure their services? This is an area of wide divergence for
the various implementors, and existing mechanisms tend to be tightly
coupled with internal mechanics of their devices. Is it possible to
agree to keep this type of material out of scope unless we find no other
reasonable way around having to describe it in the specifications to get
things to work?

> In cases where the configuration is by administrator or user 
> through a web page or some tool, and that tool is part of the 
> server that implements the feature, I think we don't need to 
> say anything about it. 
> But when configuration is to take place on one component, and 
> needs to be conveyed in an automated way to another, where 
> the feature is implemented, I think we need to talk about it.

Fair enough. I think this is reasonable.

> I think our scope covers whatever it needs to cover in order 
> to achieve interoperability.

Mmm... Really? That seems extremely ambitious. How does BLISS then
differ from SPEERMINT? 

<snip>

> > - Section 3.1.5.1 I'm not sure that assume is the best word here. 
> > People assume things, not machines. The user for UA Y 
> should clearly 
> > not expect their calls to be forwarded to anywhere if they (or an 
> > administrator) never instructed any component of the system to take 
> > some sort of action on their behalf. If nobody implements a feature 
> > there can be no interoperability, and without 
> interoperability there 
> > can be no failure to interoperate. Right?
> 
> I'm not sure I see your point. THe problem is that when an 
> administrator buys a proxy from vendor 1 and a UA from vendor 
> 2, when he puts those together, CFNA (as an example) will not 
> work. Do you disagree?

I do. I don't think it's an IETF WG's job to ensure that customers ask
appropriate questions of vendors to ensure the existance of a particular
feature. I believe it's onerous of them to have to specify detailed call
flows to make sure everything will work in RFIs, but asking both vendor
1 and vendor 2, "Do you offer feature X?" is not unreasonable at all.

Again, I think CFNA is a bad example, because it really does not require
more than one node in the network to implement it in order for it to
work. You could argue that configuration flows, such as CPL, may require
some coordination, but there are plenty of other approaches that work
without requiring CPL (and for a basic level of interoperability you
might argue against CPL implementations for this very reason).

This somewhat relates to my earlier concern about how these
specifications will be written: if CPL is simply desirable, but not
necessary for a *basic level of interoperability* what does that mean
for CPL based implementations as far as BLISS is concerned?

> > forward their calls after X rings, and then told their UA to do the 
> > same then this is clearly (to me) out of scope for a BLISS feature 
> > discussion. The protocol is working fine, the features are working 
> > fine, nothing is failing here except the user's 
> understanding of the 
> > system or their memory as to what they have told the system to do.
> 
> I think this is a case where user error is easily possible. 
> But I agree this scenario here is one of user error, whereas 
> in 3.1.5.1, it is not.

User error is always easily possible. :)

> I very much want to enable multiple places where a feature 
> can be implemented. However I want to make sure that, (1) no 
> matter what vendors you bring together, there is a 
> configuration that works, and (2) in cases where things can 
> happen in multiple places, we've worked through it and taken 
> care of any race conditions or inconsistencies that would 
> otherwise happen. In some cases, for example, I can imagine 
> needing some kind of capability discovery so that, for 
> example, a proxy can know, "hey, that UA can do call 
> forwarding, so I should not bother running the timer".
 
Except if the proxy uses such a detection mechanism, the user may
suddenly have inconsistient behavors across multiple devices. The user
may not be aware that their UA can do call forwarding. Their other
devices can't, and now when that UA is the only one logged in CFNA
breaks (because the proxy assumes the UA can do it, and the user is
unaware), whereas it works correctly when devices that cannot do CFNA
are logged in because the proxy takes over the responsibilies at that
time.

Again, we really need to be careful that by trying to simplify the
complexities we have now, we don't toss aside mechanisms that are put
there for a reason. That's why I think it's important to avoid sweeping
language in any sort of baseline material where possible.

> For our analysis of the problems (phase III in the BLISS 
> process) I think we should look at everything and then have 
> the discussion we are having right now - to determine whether 
> there is a problem here to address, or not. That is the whole 
> point of this exercise.

In general I agree with you, I just want to make sure we're not opening
up such a huge can of worms that we can't get any of them back into the
can within a reasonable amount of time. Timeliness of advice is
important otherwise our output risks being irrelevant to the people who
need it most.

[snip]

> > may matter except that CPL could be delivered to the proxy by some 
> > other source.
> 
> Sure. But in this case if it comes from the phone the system 
> doesn't work. This is exactly my point about why 
> configuration can matter.
> 
> 

Yes, it is a problem. I don't think you're going to be able to fix this
anytime soon though because configuration tends to be so closely
embedded to the idiosyncracies of how a particular node is designed
overall (perhaps leveraging hardware) that you're unlikely to reach a
meaningful consensus within a reasonable timespan. People are used to
fixing and tweaking SIP call flows, so I think the door is much more
open for recommendations than it is in the OA&M arena, for better or
worse.

> and ringtone gets downloaded to phone and executed there

Yup, these make more sense to discuss.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 09 Jul 2007 18:17:47 -0400

Section 1:

>    The SIP specification itself includes primitives to support some of
>    these features.  For example, RFC 3264 [2] defines SDP signaling
>    parameters for placing a call on hold...

(This is little more than a nit.)

RFC 3264 probably says more than it should about this. It is difficult 
to argue that those features (sendonly/recvonly) are *for* placing a 
call on hold. Rather they may *be useful when placing a call on hold*. 
The recipient of a reINVITE with a=sendonly in general cannot and should 
not conclude that it has been "put on hold".

I put some words about using offer/answer for hold in the offeranswer 
draft. But I think we could make a good case that this should be a 
subject for BLISS to pursue.

>    the logic for X.2, the outcome is unpredicable and the feature may

Agree, but there is more to it. Incompatibilities such as the above can 
result from two distinct properties of the feature implementations:

- the two techniques X.1 and X.2 are compatible, in the sense that
   a node *could* implement both techniques. But in this case both
   nodes have only implemented one technique, and not the same one.

   A solution in this case is for nodes to implement both techniques.
   When there is an option about which to use, a node could choose what
   it prefers, but it goes along when another node has already made
   a choice.

- Which action to take in a particular circumstance is indeterminate.
   Among the options consistent with a particular node's current state
   is one that is consistent with what the other node expects. But
   other actions equally plausible actions are inconsistent with the
   expectations of the other node.

   This can arise because each node has only limited information about
   the combined state of all the participants. It often doesn't know
   who all the participants are, or what feature is intended. To resolve
   this problem, it is necessary to ensure that the basic mechanisms of
   sip (used to construct features) are unambiguous wrt what each
   participant must do each time some event occurs. And then it is
   necessary to ensure that features are assembled from mechanisms in
   such a way that each node, at each event, consistently determines
   what it must do next in a way that is consistent with a reasonable
   outcome for the intended service.

   Note that problems here are quite likely not confusion between
   different implementations of the same feature. Rather they are
   likely to be confusions about what *mechanism* should be triggered
   by a particular event. The candidate mechanisms need not support
   the same feature.

   Some cases where this sort of thing can be a problem are:

   - confusion about sendonly and hold. Some b2buas conclude that
     an invite with sendonly means hold. Based on local config
     they may reinvite the other end to a MoH server.

     It may however be the case that this wasn't intended as hold
     at all. Sendonly may have been offered because there is currently
     no ability to process received media, and there is a true desire
     to send media.

   - Uses of REFER often seem to have an aura of black magic.
     Receiving a REFER request gives information that one is requested
     to send a particular type of request to a specific destination.
     It doesn't explicitly say anything about:
     . if an offer should be included (if allowed for the request)
     . which media sources and sinks managed by the device should
       be included in the request.
     . what media types should be included in a request
     . what media formats should be offered
     . How resources should be shared with other existing sessions
     . ...

     Most published call flows for features involving REFER just show
     what happens, not how a decision is made about that.

Note that even enumerating call flows for all features does not solve 
this problem, though in that case the problem will hopefully be 
discovered by developers trying to implement the features.

The problem is that you cannot implement your role in a feature by 
following the call flow. Following the call flow requires knowing the 
state of the rest of the system at all times.

Instead, the implementor of a particular node must build up a state 
machine based on information available based on the messages has 
received and sent. And then based on this state and new incoming 
messages it must decide what to do. It must consolidate the 
possibilities from all the call flows it might be participating in to 
achieve this. There is then a problem if there is some state and 
incoming event is consistent with two different call flows, which 
require different actions. There is currently no formal process to check 
if specifications have this property.

Section 3.1.3, Figure 4:

The figure is a copy of figure 3, and isn't consistent with the text. 
Looks like an editing error.

That's all. Otherwise I think this is spot on.

	THanks,
	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 9 Jul 2007 22:19:31 -0500

Comments within.

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 5:18 PM
> To: Jonathan Rosenberg
> Cc: [email-masked]
> Section 1
> RFC 3264 probably says more than it should about this. It is 
> difficult to argue that those features (sendonly/recvonly) 
> are *for* placing a call on hold. Rather they may *be useful 
> when placing a call on hold*. 
> The recipient of a reINVITE with a=sendonly in general cannot 
> and should not conclude that it has been "put on hold".

Although I agree with you technically, in reality I have yet to see a
widely available device that will not appear to go "on hold" if sent
a=sendonly. Indeed, even your own equipment does this if you look at the
Cisco IOS documentation available online (you thoughtfully allow people
to select between the bad-old way of 0.0.0.0 or a=sendonly).

Are we looking for best-possible implementation or basic level of
interoperability? These are two very different things.

> 
> I put some words about using offer/answer for hold in the 
> offeranswer draft. But I think we could make a good case that 
> this should be a subject for BLISS to pursue.
> 
[snip]

>      no ability to process received media, and there is a true desire

Plausible but not very commmon for audio streams. Definitely more likely
with video streams. You left out one important detail about the way most
BBUAs handle MoH though, it's not that the media stream was set to
sendonly... It's that the media stream TRANSITIONED to a=sendonly from
a=sendrecv. You'll get all sorts of weird, yet avoidable, usecases if
you don't implement this tracking behavior. If everyone is happy with
using a=sendonly to denote hold (based on what we see that they've
implemented) no matter how wrong it may be, wouldn't this indicate a
successful level of interoperability?

Again, trying to plumb where people's thoughts are: solve world hunger,
fix only the really bad stuff and leave the rest, or just find a way to
make everything work and call it a day.

> Note that even enumerating call flows for all features does 
> not solve this problem, though in that case the problem will 
> hopefully be discovered by developers trying to implement the 
> features.
> 
> The problem is that you cannot implement your role in a 
> feature by following the call flow. Following the call flow 
> requires knowing the state of the rest of the system at all times.
> 
> Instead, the implementor of a particular node must build up a 
> state machine based on information available based on the 
> messages has received and sent. And then based on this state 
> and new incoming messages it must decide what to do. It must 
> consolidate the possibilities from all the call flows it 
> might be participating in to achieve this. There is then a 
> problem if there is some state and incoming event is 
> consistent with two different call flows, which require 
> different actions. There is currently no formal process to 
> check if specifications have this property.

Agree whole-heartedly. Call flow diagrams are tools of the devil. They
fool developers into thinking they have a complete implementation based
on their ability to reproduce a limited number of message flow diagrams
instead of understanding what the heck is really going on. They're
useful for purposes of discussion but somewhat evil for purposes of
specification (unless you want to spend a really large chunk of time
enumerating and managing them). State-machine diagrams are much simpler
to verify and still get you the a-picture-is-worth-a-thousand-words
benefits you can get with a call flow diagram.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jul 2007 08:25:49 -0400

> to select between the bad-old way of 0.0.0.0 or a=sendonly).

In general I don't control what Cisco builds. I know it has lots of 
things that violate lots of rules. I exert the influence I can.

But I'm not sure exactly what you are saying here. In general it isn't 
necessary for the device on the receiving end to know whether it is on 
hold or not. What does it mean to "appear to go on hold"?

Its different on the originating end. Of course it knows that it is 
going on hold.

> benefits you can get with a call flow diagram.

I don't think they are tools of the devil. They are quite useful - 
necessary but not sufficient.

 From a UML modeling perspective a call flow diagram is an "interaction 
diagram". It is useful for detailing a single use case. But of course a 
single use case doesn't make an algorithm. A collection of use cases is 
useful input for creating an algorithm.

	Thanks,
	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 10 Jul 2007 10:16:13 -0500

> Sent: Tuesday, July 10, 2007 7:26 AM
> Cc: Jonathan Rosenberg; [email-masked]
> are *for* 
> >> placing a call on hold. Rather they may *be useful when placing a 
> >> call on hold*.
> >> The recipient of a reINVITE with a=sendonly in general cannot and 
> >> should not conclude that it has been "put on hold".
> > 
> > a=sendonly. Indeed, even your own equipment does this if 
> you look at 
> > the Cisco IOS documentation available online (you 
> thoughtfully allow 
> > people to select between the bad-old way of 0.0.0.0 or a=sendonly).
> 
> In general I don't control what Cisco builds. I know it has 
> lots of things that violate lots of rules. I exert the 
> influence I can.
> 
> But I'm not sure exactly what you are saying here. In general 
> it isn't necessary for the device on the receiving end to 
> know whether it is on hold or not. What does it mean to 
> "appear to go on hold"?
> 
> Its different on the originating end. Of course it knows that 
> it is going on hold.

Where applicable, devices tend to denote that they're on hold: flashing
icon/button/etc, when they've been sent a=sendonly after having been at
a=sendrecv previously.

My point was the question you didn't answer (just below): Are we looking
for best-possible implementation or basic level of interoperability?
These are two very different things.

> offeranswer 
> > Plausible but not very commmon for audio streams. Definitely more 
> > likely with video streams. You left out one important 
> detail about the 
> > way most BBUAs handle MoH though, it's not that the media 
> stream was 
> > set to sendonly... It's that the media stream TRANSITIONED to 
> > a=sendonly from a=sendrecv. You'll get all sorts of weird, yet 
> > avoidable, usecases if you don't implement this tracking 
> behavior. If 
> > everyone is happy with using a=sendonly to denote hold 
> (based on what 
> > we see that they've
> > Again, trying to plumb where people's thoughts are: solve world 
> > hunger, fix only the really bad stuff and leave the rest, 
> or just find 
> > a way to make everything work and call it a day.

Did you have any opinion on the above?

> >> require different actions. There is currently no formal process to 
> > fool developers into thinking they have a complete implementation 
> > based on their ability to reproduce a limited number of 
> message flow 
> > diagrams instead of understanding what the heck is really going on. 
> > They're useful for purposes of discussion but somewhat evil for 
> > purposes of specification (unless you want to spend a really large 
> > chunk of time enumerating and managing them). State-machine 
> diagrams 
> > are much simpler to verify and still get you the 
> > a-picture-is-worth-a-thousand-words
> I don't think they are tools of the devil. They are quite 
> useful - necessary but not sufficient.
> 
>  From a UML modeling perspective a call flow diagram is an 
> "interaction diagram". It is useful for detailing a single 
> use case. But of course a single use case doesn't make an 
> algorithm. A collection of use cases is useful input for 
> creating an algorithm.

Agree, but people tend to look at the diagrams and less at the words.
I've gone through many interop exercises that were built solely around
call flow diagrams and they tend to suck up a LOT more time than
necessary and produce a comparitively poor result. Specifying the
algorithm is far more useful.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jul 2007 15:16:11 -0400

> These are two very different things.

I think for bliss we should be satisfied with a basic level of 
interoperability. In the case at hand I am satisfied that each end can 
go on and off hold as it desires, and that media flows (or doesn't flow) 
as desired. When I initiate "hold" I don't have any particular 
expectation that the other end is told explicitly that it has been put 
on hold. So the lack of an explicit "hold" indication on the far end 
doesn't bother me.

However, in this particular case, it is indeed good for the far end to 
indicate that that it isn't permitted to transmit media. That is equally 
useful regardless of the reason. I don't require it, but it is a plus.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 12 Jul 2007 20:03:28 +0100

Jonathan,

I like the methodology proposed.

One point of detail concerning the particular example given:

"In the case of CFNA, clearly a functional
   primitive of "call forwarding features that execute on no-answer" is
   too narrow.  A functional primitive of "features that handle an
   initial INVITE" is too broad.  An ideal starting point would probably
   be, "features that result in a retargeting or response operation that
   depend on user-specified criteria".  This covers all of the call
   forwarding variations, but also includes features like Do-Not-
   Disturb."

I agree that one action that can be taken on DND is to forward (e.g., to
voicemail, to an assistant). However, the bliss-dnd draft covers more
than this, in particular what to indicate to the caller, how to clearly
indicate DND to the proxy if the proxy is responsible for forwarding,
and what to indicate in presence. These aspects are somewhat different
from the call forwarding set of problems. I prefer to regard it as an
interaction between two groups of features (or two functional
primitives) - the DND group and the forwarding group. In fact the
problem of interactions will come up a lot, for example impact of call
forwarding on shared line appearance. We have to draw lines between
groups of features somewhere and accept that there will be interactions
between groups and find out ways to handle these interactions (in a way
that does not constrain implementations but does not lead to
unpredictable or undesirable behaviour). Otherwise we will end up with
just one huge and unmanageable group.

John

> Sent: 02 July 2007 23:31
> back, so that

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 16 Jul 2007 10:43:38 +0200

Hi Jonathan, 

I have a few questions for clarification. 

First, how are we going to define each feature? Will we do a "feature definition", or will we (if possible) use existing documentation which defines the features? For example, the feature names you have listed all exist as supplementary services, with existing service definition.

Second, chapter 5.2 says "Participants can also suggest flows they think might exist". Does that cover flows that other SDOs have produced, e.g. a TISPAN flow for a supplementary service which is similar to a specific "feature"?

Regards, 

Christer 

> Sent: 3. heinäkuuta 2007 1:31
> To: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 16 Jul 2007 08:25:46 -0400

> Hi Jonathan, 

I'm not speaking for Jonathan. The following is my opinion.

> First, how are we going to define each feature? Will we do a "feature definition", or will we (if possible) use existing documentation which defines the features? For example, the feature names you…

My experience is that it is very difficult to get universal agreement on 
the precise definition of features. There are indeed lots of definitions 
of similar features. For that reason Jonathan is focusing on loosely 
defined groups of similar/related features.

> Second, chapter 5.2 says "Participants can also suggest flows they think might exist". Does that cover flows that other SDOs have produced, e.g. a TISPAN flow for a supplementary service which is s…

IMO it is quite appropriate to bring in definitions from other SDOs.

	Paul

---

From: [email-masked]
Date: Mon, 16 Jul 2007 09:13:55 -0400

Christer,

Paul Kyzivat <[email-masked]> wrote:
> > First, how are we going to define each feature? Will we do a "feature 
definition", 
> > or will we (if possible) use existing documentation which defines the 
features? 
> > For example, the feature names you have listed all exist as 
supplementary services, 
> > with existing service definition.

I guess I suffer a knee-jerk negative reaction to the term "feature 
definition"
because I am suddenly thinking in terms of *marketing* definitions of 
features.
And the reality is that to a degree those definitions will always be 
different as
vendors try for "competitive differentiation".  ("Our call forwarding 
works better
that Vendor X's because we maximize the synergistic relativity paradigm", 
etc.)

How precisely do you want to define a feature?  Or are you thinking in 
terms of the
feature interoperability?

I guess my concern with using 'existing documentation' would come back to 
"whose 
documentation do you use?"  If it's documentation from another standards 
body, I don't
really have an issue.  If it is documentation from a vendor, we'll get 
into all sorts
of concerns from other competing vendors, IMHO.

> defined groups of similar/related features.

I agree with Paul that we should avoid getting bogged down in the precise 
definitions
of features and stay focused on defining the mechanism that allows 
interoperability. 

To jump to a completely different context, vendor A may be say "tomato" as 
"toe-MAY-toe"
and view it as a vegetable.  Vendor B may spell it "tomatoe", say it 
"toe-MAH-toe" and view
it as a fruit.  We (IETF) need to be saying that however you spell it, say 
it or view it, 
if you slice it in this particular way it will sit nicely on most 
hamburgers or sandwiches.

> > Second, chapter 5.2 says "Participants can also suggest flows they 
think might exist". 
> > Does that cover flows that other SDOs have produced, e.g. a TISPAN 
flow for a 
> > supplementary service which is similar to a specific "feature"?
> 

Agreed.

My 2 cents,
Dan

-- 
Dan York, CISSP
Dir of IP Technology, Office of the CTO
Mitel       http://www.mitel.com
[email-masked] +1-613-592-2122
PGP key (F7E3C3B4) available for 
secure communication

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 17 Jul 2007 12:28:59 +0200

Hi, 

>>Ihave a few questions for clarification. 
>> 
definition", 
features? 
supplementary services, 
definition" 
features. 
different as 
works better 
>that Vendor X's because we maximize the synergistic relativity
paradigm", etc.) 
terms of the 
>I guess my concern with using 'existing documentation' would come back
to "whose 
>documentation do you use?"  If it's documentation from another
standards body, I don't 
into all sorts 
>of concerns from other competing vendors, IMHO. 

When it comes to features based on standardized supplementary services,
I was thinking of documentation from other standard bodies, not from
specific vendors.
	
>defined groups of similar/related features.

The preciseness can be discussed.

>I agree with Paul that we should avoid getting bogged down in the
precise definitions 
interoperability.   

You need to say what the feature is supposed to do, in order to allow
interoperability.
	
>To jump to a completely different context, vendor A may be say "tomato"
as "toe-MAY-toe" 
"toe-MAH-toe" and view 
>it as a fruit.  We (IETF) need to be saying that however you spell it,
say it or view it, 

Yes, but unless you define that you are going to slice the tomato,
someone could make ketchup out of it...

Yes, you can still put ketchup on your burger, but if I ask for sliced
tomates I don't get what I want :)

Regards,

Christer

---

From: [email-masked]
Date: Tue, 17 Jul 2007 10:17:49 -0400

Christer,

> I was thinking of documentation from other standard bodies, not from

Sounds reasonable.

> You need to say what the feature is supposed to do, in order to allow

I completely agree... perhaps I am just getting hung up on "feature
definition" and the level to which it is described. I guess when I think
of something like "DND", we do need a high-level "definition" that says
what it will do and then agreement on how to interoperate (really the
"feature groups" of Jonathan's text).  My concern is how far down we
define what "DND" is and does.  If we get extremely specific, it may
cause friction with some vendors who want more flexibility.

As I write this, though, it does occur to me that one of the simplest
approaches may just be to see how specific we *can* make these initial
4 pieces of the SIP interop puzzle and just say "if you want to be
interoperable, thou shalt implement it THIS way" and be done with it.
If we can get enough of the vendors behind a specific implementation
we'd have the market pressure that would encourage others to come along.
(If only things were that simple...)
 
> > We (IETF) need to be saying that however you spell it,
> say it or view it, 

Many thanks for the witty response... it gave me a good laugh!

Regards,
Dan

---

From: Shida Schubert <[email-masked]>
Date: Wed, 18 Jul 2007 16:00:36 -0700

Brian;

 My personal comment on the remark you made here.. Sorry for budding
in so late.

> Mmm... Really? That seems extremely ambitious. How does BLISS then
 I have to agree with Jonathan here, but would be careful with how much 
BLISS
would take on.
  After the analysis of the problem and coming up with a potential 
solution to resolve the
  interop problems, if we decide that a way to communicate configuration 
means between
  components is intrinsic, then I see no reason why we couldn't address 
the issue within the
  group, of course if new SIP extension, extension to RPID etc. is 
needed then the task should
  be delegated to an appropriate WG such as SIP and SIMPLE.

 Further, if we see way to improve the interop problems to some level 
but see that sorting
out the configuration means through negotiation for example would 
improve the interop
problems even more, I see no reason why we can't produce multiple 
documents to relieve
some of the headaches and later try to relieve more with whatever is 
considered desirable.

 Similar to error correction approach taken in SIP WG for example may be 
acceptable
here as well, not desirable definitely, but if it looks like we can save 
70% of the problems
with the first approach and 95% if we pursue with the more complicated 
approach that
may take year or more then, I feel that we should release whatever we 
need to save the 70%
and later release the latter.

 Regards
  Shida

---

From: Shida Schubert <[email-masked]>
Date: Wed, 18 Jul 2007 16:31:16 -0700

Hi Paul, Brian;

 My personal view on this is that BLISS will provide a basic level
of interoperability through recommending primitives to implement
and recommending behavior to be implemented by the components.

 We are really trying to recommend a flavor of an implementation
for the target functional primitive which may be analogous to
best-possible implementation for interoperability.

 It may seem too restrictive by recommending a particular implementation,
but let's not forget for a moment, that we are focusing on functional 
primitives
and not a whole feature here. I view functional primitive to be a mere 
fraction
of a whole feature that uses the functional primitive, but at the same 
time the
major source of the problems.

 Being stringent with how functional primitive are implemented SHOULD
NOT forbid vendors to come up with variations in providing the feature
that utilizes the primitive function as long as it's not the whole 
feature that
BLISS is defining.

 Further, some of the pre-existing implementations that has 
interoperability
problems may be saved by the recommendation but between the pre-existing
implementations that has problems, the problem will persists and some of 
the
variants may not be saved by the recommendation if saving that variant 
means
90% of the overall effort needed to solve the overall problem.

 I believe what we are doing here is simply trying to make the future
better by recommending a way to implement a portion of the feature 
that's causing
the problem and save whatever we can save while we are at it.

 Regards
  Shida

Paul Kyzivat wrote:
> go on and off hold as it desires, and that media flows (or doesn't 
> flow) as desired. When I initiate "hold" I don't have any particular 
> indicate that that it isn't permitted to transmit media. That is 
> equally useful regardless of the reason. I don't require it, but it is 
> a plus.
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jul 2007 21:31:37 -0400

I agree with you.

Also, in most cases there is one participant in a feature that is the 
initiator. That participant knows what feature is being invoked. If 
there are multiple ways to do the feature, that participant has freedom 
in which way to do it. It may be constrained to some extent by what 
functionality the peer had advertised support for. But the support it 
depends on is not for features, but rather only for various primitives.

The other participant(s) are more in the way bystanders. They don't know 
what feature they are being asked to participate in. Rather, they get 
some stimulus - typically a request in the context of some state the 
node has, and then must react to that by doing something.

What's important is that the non-initiating participants do what is 
necessary to allow the completion of the service kicked off by the 
initiator, even if they would never have initiated the service the same 
way if they were the initiator.

Of course is isn't really that simple. The non-initiating participants 
may still have some discretion in initiating the next step in a complex 
sequence.

So I think the key things we need to do are:
- ensure that different features don't result in an identical
   stimulus to some participant while requiring that participant
   to take a different action for each feature. (Since it doesn't
   know what feature it is doing.)

- Get agreement on what the set of stimulus:action pairs need to
   be supported to allow any of the interesting feature implementations
   to be kicked off by an initiator.

The hope and expectation (at least by me) is that the number of 
stimulus:action pairs that must be supported is much less than the 
number of feature implementations, because the same stimulus:action pair 
is used by many features.

	Thanks,
	Paul

Shida Schubert wrote:
> Further, some of the pre-existing implementations that has interoperability

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sat, 21 Jul 2007 20:50:59 +0200

Hi, 

>I agree with you.
> 
>Also, in most cases there is one participant in a feature 
>that is the initiator. That participant knows what feature is 
>being invoked. If there are multiple ways to do the feature, 
>that participant has freedom in which way to do it. It may be 
>constrained to some extent by what functionality the peer had 
>advertised support for. But the support it depends on is not 
>for features, but rather only for various primitives.
> 
>The other participant(s) are more in the way bystanders. They 
>don't know what feature they are being asked to participate 
>in. Rather, they get some stimulus - typically a request in 
>the context of some state the node has, and then must react 
>to that by doing something.
> 
>What's important is that the non-initiating participants do 
>what is necessary to allow the completion of the service 
>kicked off by the initiator, even if they would never have 
>initiated the service the same way if they were the initiator.

Beavis, you just said "service"... huh huh huh ;)

>Of course is isn't really that simple. The non-initiating 
>participants may still have some discretion in initiating the 
>next step in a complex sequence.
>
> 
>The hope and expectation (at least by me) is that the number 
>of stimulus:action pairs that must be supported is much less 
>than the number of feature implementations, because the same 
>stimulus:action pair is used by many features.

This sounds a little like the work on "common procedures" that TISPAN
has been working on, which defines common building blocks/sub-functions
that services can refer to.

Regards,

Christer

> 	Thanks,
> 	Paul
> 
> Shida Schubert wrote:
> > 
> > Hi Paul, Brian;
> > 
> > My personal view on this is that BLISS will provide a basic 
> level of 
> > interoperability through recommending primitives to implement and 
> > recommending behavior to be implemented by the components.
> > 
> > We are really trying to recommend a flavor of an implementation for 
> > the target functional primitive which may be analogous to 
> > It may seem too restrictive by recommending a particular 
> > implementation, but let's not forget for a moment, that we are 
> > focusing on functional primitives and not a whole feature 
> here. I view 
> > functional primitive to be a mere fraction of a whole feature that 
> > uses the functional primitive, but at the same time the 
> major source 
> > of the problems.
> > 
> > feature that BLISS is defining.
> > 
> > interoperability problems may be saved by the recommendation but 
> > between the pre-existing implementations that has problems, the 
> > problem will persists and some of the variants may not be 
> saved by the 
> > recommendation if saving that variant means 90% of the 
> overall effort 
> > needed to solve the overall problem.
> > 
> > that's causing the problem and save whatever we can save 
> while we are 
> > at it.
> > 
> > Regards
> >  Shida
> > 
> > Paul Kyzivat wrote:
> >>
> >>
> >> Brian Stucker wrote:
> >>
> >>>
> >>> My point was the question you didn't answer (just below): Are we 
> >>> looking for best-possible implementation or basic level 
> of interoperability?
> >> interoperability. In the case at hand I am satisfied that each end 
> >> can go on and off hold as it desires, and that media flows (or 
> >> doesn't
> >> expectation that the other end is told explicitly that it has been 
> >> put on hold. So the lack of an explicit "hold" indication 
> on the far 
> >> end doesn't bother me.
> >>
> >> However, in this particular case, it is indeed good for 
> the far end 
> >> to indicate that that it isn't permitted to transmit 
> media. That is 
> >> equally useful regardless of the reason. I don't require 
> it, but it 
> >> is a plus.
> >>
> >>     Thanks,
> >>     Paul
> >>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Jul 2007 17:22:26 -0400

inline.

> depends on is not for features, but rather only for various primitives.

I think we need to be VERY careful here. In all cases, we are expecting 
*something* to be present, in terms of functionality, from the 
non-intiators, even in single-ended features. At a minimum, we are 
expecting RFC 3261. In many cases, we may be expected support for 
something like REFER. If a UA doesn't support receipt of REFER, then the 
feature doesn't work even if you think its single ended.

As such, even for single ended features, we will need to state minimum 
requirements (i.e., implement REFER) for that feature group.

> way if they were the initiator.

Right.

> may still have some discretion in initiating the next step in a complex 

If the feature requires the non-initiating participants to do something 
that is specific to this feature, it is by definition, not single-ended.

>   know what feature it is doing.)

Right. We need to look very carefully about what expectations we have 
for non-participants. Even for something like receipt of REFER, you need 
to make sure that the UA has what it needs to authorize the request.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Jul 2007 17:28:48 -0400

inline.

> I like the methodology proposed.

Thanks.

> and what to indicate in presence.

Well, I'd argue that all of these apply to CFNA also. It is desirable to 
indicate to the caller that their call is being forwarded. Obviously 
we'd need to indicate to the proxy how to do forwarding if its desired. 
Even presence. For example, if CFNA is enabled, you might include a 
<relationship> element in the presence document.

> These aspects are somewhat different
> primitives) - the DND group and the forwarding group. 

I'm not sure I agree.

In fact the
> just one huge and unmanageable group.

The purpose of 'groups' is to understand interactions between components 
that are required for that feature, and to focus on those interactions 
that are the source of interop problems. In the case of CFNA and DND, 
there are identical interactions, so to me, they are the same group.

Also note that if any one particular feature doesn't implement 
everyuthing defined by the group, thats fine too. We're not specifying 
how to do DND - we're not REQUIRING that anyone set presence based on 
it. So, if someones CFNA feature doesn't use presence, thats fine. It 
doesn't mean its a different group.

The definition of the groups is not based on feature interactions 
between groups, and lack of interactions within a group. Its based 
entirely on a common set of protocol procedures that all of the features 
in a group require in order to interoperate.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Jul 2007 17:31:15 -0400

Christer Holmberg (JO/LMF) wrote:
> First, how are we going to define each feature?

We're not.

> Will we do a "feature
> definition", or will we (if possible) use existing documentation
> which defines the features? 

Neither.

> For example, the feature names you have
> listed all exist as supplementary services, with existing service
> definition.

Sure. And so?

The thing we are defining are functional groups. These groups are 
defined by a common set of protocol interactions and mecahnisms amongst 
elements in the network, which are common. The abstract and introduction 
of our specification would give example features that fit into the 
category. The precise definition is not relevant.

> think might exist". Does that cover flows that other SDOs have
> produced, e.g. a TISPAN flow for a supplementary service which is
> similar to a specific "feature"?

Yes, sure. I'd love to see drafts with those proposed.

-Jonathan R.

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 23 Jul 2007 22:52:12 +0100

> Sent: 23 July 2007 22:29
> To: Elwell, John
> indicate to the caller that their call is being forwarded. 
[JRE] For CFNR and other call forwarding variants we already have a
provisional response, 181, for this, whereas for DND we need a final
response.

> Obviously 
[JRE] Do you have in mind here instructing the proxy in advance (e.g.,
by CPL script), or instructing the proxy at call attempt time (using 302
response)? I agree the former is common, although I am not sure this is
within the scope of BLISS (it would be done by non-SIP means). The
latter doesn't apply to DND.

> <relationship> element in the presence document.
[JRE] True, although a different indication would be needed here.

> there are identical interactions, so to me, they are the same group.
[JRE] Well, I am not convinced. Anyway, during my slot in BLISS tomorrow
I will be raising this issue, so perhaps we will get other opinions.

> doesn't mean its a different group.
[JRE] I agree that you don't have to implement everything in a group. So
if a group includes CFNR, CFB and CFU, it should not oblige everyone to
implement all three. But I am not convinced that DND is part of that
group (but forwarding due to DND is).

> in a group require in order to interoperate.
[JRE] The ability to indicate a DND condition as a reason for call
rejection is not a protocol procedure that is required by call
forwarding features.

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 23 Jul 2007 17:01:17 -0500

A few comments inline... 

> Sent: Monday, July 23, 2007 4:22 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> that is the 
> > there are multiple ways to do the feature, that participant has 
> > freedom in which way to do it. It may be constrained to 
> some extent by 
> > what functionality the peer had advertised support for. But the 
> > support it depends on is not for features, but rather only 
> for various primitives.
> 
> *something* to be present, in terms of functionality, from 
> the non-intiators, even in single-ended features. At a 
> minimum, we are expecting RFC 3261. In many cases, we may be 
> expected support for something like REFER. If a UA doesn't 
> support receipt of REFER, then the feature doesn't work even 
> if you think its single ended.
> 
> As such, even for single ended features, we will need to 
> state minimum requirements (i.e., implement REFER) for that 
> feature group.

I'd argue that the only single-ended features are ones that expect the
other endpoint to be willing and able to establish a session. I don't
even think the non-initiator should be required to understand SIP;
meaning, that the feature still works with a SIP-to-foo gateway (where
nothing is known about the workings of the foo protocol) in front of the
non-initiating endpoint.

If you require the non-initiator to do more, then the feature is not
single-ended. You're requiring some level of cooperation or willingness
to be manipulated by the non-initiator in order to make the feature
operate. That's what I meant earlier as the dividing line between what
is single-ended and what is double-ended.

Single ended features require no state to be created or transferred
between the initiator and the non-initiator of a feature beyond what is
required to successfully setup the most basic dialog possible because
this is the minimum amount of state required to be created in the
non-initiating client. Everything else is incremental and makes
assumptions about the non-initiator's behavior.

I don't see how any feature which uses REFER (just to pick an example)
could ever be single-ended, whereas you can definitely implement Call
Forwarding as a single-ended feature in which the non-initiator may not
even be able to detect that the feature had been invoked.

I definitely do agree that stating the minimum requirements for a
feature group would be necessary.

> 
> > 
> > The other participant(s) are more in the way bystanders. They don't 
> > know what feature they are being asked to participate in. 
> Rather, they 
> > get some stimulus - typically a request in the context of 
> some state 
> > the node has, and then must react to that by doing something.
> > 
> > initiator, even if they would never have initiated the service the 
> > same way if they were the initiator.
> 
> 
> Right.

By definition, a bystander does not get involved in something. It simply
observes what is going on with no requirement to take action or even
understand what it is observing. If we're requiring the non-initiator to
take action upon our requests (stimulus), it may not need to know where
the initiator is ultimately trying to do (i.e. the feature) but it must
be willing to 'play-along'.

> participants 
> > may still have some discretion in initiating the next step in a 
> > complex sequence.
> 
> If the feature requires the non-initiating participants to do 
> something that is specific to this feature, it is by 
> definition, not single-ended.

Again, I would argue that if they require the non-initiating
participants to do something that is beyond basic dialog establishment,
then it is not single-ended.

> Right. We need to look very carefully about what expectations 
> we have for non-participants. Even for something like receipt 
> of REFER, you need to make sure that the UA has what it needs 
> to authorize the request.

Agree.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Jul 2007 18:54:51 -0400

I think this is a good definition for single-ended - that it doesn't 
require other participants to do anything beyond that which would be 
needed for the most basic call setup.

By this definition, almost nothing is single ended....

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 23 Jul 2007 19:03:23 -0400

> provisional response, 181, for this, whereas for DND we need a final

OK, fair point. But I'm not sure that different requires a whole other 
deliverable. A single specification that covers different types of 
treatment - rejection, forwarding, redirection, etc., would suffice.

Also, its only important to specify what is necessary for interop. As 
such it may not be necessary to say anything about specific response 
codes back to the originator. What actual interop problem shows up if 
the originator gets a simple 400 for DND, rather than something that 
explicitly says, "your call was rejected due to DND"?

And if DND causes a call to go to voicemail, clearly in that case there 
is no rejection response.

> response)?

My own preference is instructing the proxy to advance. User expectation 
in many cases that, from a UA, a user can select "call forward 
unconditional" or whatever, and that happens. So that needs to be 
signaled. I tend to prefer this in the proxy, largely due to forking 
complexities.

> I agree the former is common, although I am not sure this is

As per other discussions, I think it is within our scope to make 
recommendations on this kind of 'provisioning' only when there is a 
clear requirement for an automated way to convey it from a component to 
another.

> rejection is not a protocol procedure that is required by call

per above, what is the interoperability failure you are concerned about 
if the element implementing DND uses a response code of its choice?

-Jonathan R.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jul 2007 19:22:20 -0400

> By this definition, almost nothing is single ended....

In that case its not a useful concept. Maybe "single ended" is 
uninteresting. I used the terms "initiator" and "bystander". The 
bystander is still a participant and may have a role to play in features 
that are not "single ended".

We currently have primitives, such as REFER, that in theory can be acted 
upon without context of why they were received. I hope in some cases 
features that use such techniques can still work with bystanders that 
don't have any special context, or knowledge of the feature invoked by 
the initiator.

The key is discovering the cases where this is *not* the case. Before 
those can be successful there must be a way to ensure that the bystander 
*does* have "enough" context to unambiguously decide what to do. This in 
general *does not* require that the bystander have enough context to 
know exactly what feature is being executed.

	Paul

>>> From: Jonathan Rosenberg [mailto:[email-masked]] Sent: Monday, 
>>> July 23, 2007 4:22 PM
>>> To: Paul Kyzivat
>>> Cc: [email-masked]
>>> something like REFER. If a UA doesn't support receipt of REFER, then 
>>> the feature doesn't work even if you think its single ended.
>>>
>>> As such, even for single ended features, we will need to state 
>>> minimum requirements (i.e., implement REFER) for that feature group.
>>
>>> something that is specific to this feature, it is by definition, not 
>>> single-ended.
>>
>>> for non-participants. Even for something like receipt of REFER, you 
>>> need to make sure that the UA has what it needs to authorize the 
>>> request.
>>
>> Agree.
>>
>>> -Jonathan R.
>>> --

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 23 Jul 2007 18:52:02 -0500

Yeah, probably a little draconian.

Perhaps we could take single-endedness to mean that there's no state
requirement (outside of basic protocol requirements) on the
non-initiator of the feature. For example, if a feature sends a REFER to
another endpoint, and the feature doesn't require some state to be
created or pre-exist outside of basic REFER processing, that may also
qualify.

Looking for a good middle ground to essentially describe the case where
one side of the call doesn't have to do anything special outside of
supporting widely implemented protocol primitives (I know, slippery
ground).

It would essentially mean then whether or not you can manipulate the
non-initiator into taking all of the necessary steps to appear to
understand a particular feature that it does not claim support for. For
example, the non-initiator may not support consultative call transfer,
but it does support REFER. To the initiator of a consultative call
transfer feature that uses only primitives such as REFER, the feature
appears to work even though the non-initiator wasn't doing anything
specific to that feature: it's single-ended.

This is essentially what I was trying to go for here.

Regards,
Brian

> Sent: Monday, July 23, 2007 5:55 PM
> Cc: Paul Kyzivat; [email-masked]
> I think this is a good definition for single-ended - that it 
> doesn't require other participants to do anything beyond that 
> which would be needed for the most basic call setup.
> 
> > nothing is known about the workings of the foo protocol) in 
> front of 
> > the non-initiating endpoint.
> > 
> > single-ended. You're requiring some level of cooperation or 
> > willingness to be manipulated by the non-initiator in order to make 
> > the feature operate. That's what I meant earlier as the 
> dividing line 
> > between what is single-ended and what is double-ended.
> > 
> > between the initiator and the non-initiator of a feature 
> beyond what 
> > is required to successfully setup the most basic dialog possible 
> > because this is the minimum amount of state required to be 
> created in 
> > the non-initiating client. Everything else is incremental and makes 
> > Forwarding as a single-ended feature in which the non-initiator may 
> > not even be able to detect that the feature had been invoked.
> > 
> > By definition, a bystander does not get involved in something. It 
> > simply observes what is going on with no requirement to 
> take action or 
> > even understand what it is observing. If we're requiring the 
> > non-initiator to take action upon our requests (stimulus), 
> it may not 
> > need to know where the initiator is ultimately trying to do 
> (i.e. the 
> > feature) but it must be willing to 'play-along'.
> > 
> > participants to do something that is beyond basic dialog 
> > establishment, then it is not single-ended.
> >

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 23 Jul 2007 18:57:06 -0500

> Sent: Monday, July 23, 2007 6:22 PM
> To: Jonathan Rosenberg
> Cc: Stucker, Brian (RICH1:AR00); [email-masked]
> In that case its not a useful concept. Maybe "single ended" 
> is uninteresting. I used the terms "initiator" and 
> "bystander". The bystander is still a participant and may 
> have a role to play in features that are not "single ended".

I'm having a difficult time following what you mean by "bystander". By
definition, a bystander cannot be a participant. 

> 
> We currently have primitives, such as REFER, that in theory 
> can be acted upon without context of why they were received. 
> I hope in some cases features that use such techniques can 
> still work with bystanders that don't have any special 
> context, or knowledge of the feature invoked by the initiator.

Sounds familiar. :)

> 
> The key is discovering the cases where this is *not* the 
> case. Before those can be successful there must be a way to 
> ensure that the bystander
> *does* have "enough" context to unambiguously decide what to 
> do. This in general *does not* require that the bystander 
> have enough context to know exactly what feature is being executed.

Outside of normal protocol restrictions, such as "don't send a REFER on
a dialog that is not yet confirmed" I think the only state you can rely
upon as the initiator is whatever you can determine unambiguously from
the outcome of the previously applied primitive operations. If you need
more, it's definitely double-ended. You're having to collude with the
non-initiator (I think what you're referring to here as a bystander) to
make things work.

> >> I'd argue that the only single-ended features are ones that expect 
> >> the other endpoint to be willing and able to establish a 
> session. I 
> >> don't even think the non-initiator should be required to 
> understand 
> >> SIP; meaning, that the feature still works with a 
> SIP-to-foo gateway 
> >> (where nothing is known about the workings of the foo protocol) in 
> >> front of the non-initiating endpoint.
> >>
> >> I don't see how any feature which uses REFER (just to pick an 
> >> example) could ever be single-ended, whereas you can definitely 
> >> implement Call Forwarding as a single-ended feature in which the 
> >> non-initiator may not even be able to detect that the 
> feature had been invoked.
> >>
> take action 
> >> or even understand what it is observing. If we're requiring the 
> >> need to know where the initiator is ultimately trying to 
> do (i.e. the 
> >>> Right. We need to look very carefully about what expectations we 
> >>> have for non-participants. Even for something like 
> receipt of REFER, 
> >>> you need to make sure that the UA has what it needs to 
> authorize the 
> >>> request.
> >>
> >> Agree.
> >>
> >>> -Jonathan R.
> >>> --

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jul 2007 01:03:13 +0100

Jonathan,

> if the element implementing DND uses a response code of its choice?
[JRE] If a UAS sends one response code and a proxy programmed to forward
on DND expects a different response code, this will result in failure. I
agree that the response code the UAC receives is unimportant from an
interoperability point of view (but might still be important for
conveying appropriate information to the caller - similar motivation to
that for extending RPID to indicate DND explicitly).

John

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 24 Jul 2007 04:23:47 +0200

Hi, 

>>Will we do a "feature definition", or will we (if possible) use
existing documentation which 
>>defines the features?
>>supplementary services, with existing service definition.
> 
>Sure. And so?

Well, if we are supposed to provide flows on how features are
implemented (and then try to create feature groups based on common
interop issues), we need to know what the features are supposed to do -
and that is normally specified in a feature definition...

>The thing we are defining are functional groups. These groups 
>are defined by a common set of protocol interactions and 
>mecahnisms amongst elements in the network, which are common. 
>The abstract and introduction of our specification would give 
>example features that fit into the category. The precise 
>definition is not relevant.
> 
>> 

Unless I'm wrong, the 3GPP specifications are available to everyone
(3GPP has endorsed most of the TISPAN services), so the flows could
maybe be taken from there in that case.

Regards,

Christer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2007 10:31:15 -0400

If the term and concept doesn't actually help us, there may be little 
point in debating what it is.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Jul 2007 10:33:44 -0400

I think this is presuming that the UA 'invokes' DND by receiving the 
request and then responds, and then the proxy takes some action on the 
response.

What you are saying is, we need a standard way to signal invocation of 
DND from a UA to a proxy that is executing it. To that, I agree. 
However, there are many ways to implement this, and its not obvious that 
the way you describe (using a response code from UA to proxy) is the 
right one. This is why I've felt that an important part of the BLISS 
process is to ENUMERATE the different ways people have realized this, 
find where things break, and determine what it is we do need to standardize.

Thanks,
Jonathan R.

---

From: "Brian Stucker" <[email-masked]>
Date: Tue, 24 Jul 2007 09:49:23 -0500

I think it does help us, because the interop interactions of a
single-ended feature are much simpler to deal with as opposed to
something that is double-ended. I wouldn't say that I'm debating what it
is so much as trying to find a balance between making it useful and not
expecting too much of the various implementations.

Regards,
Brian  

> Sent: Tuesday, July 24, 2007 9:31 AM
> If the term and concept doesn't actually help us, there may 
> be little point in debating what it is.
> 
> -Jonathan R.
> 
> Brian Stucker wrote:
> > non-initiator of the feature. For example, if a feature 
> sends a REFER 
> > to another endpoint, and the feature doesn't require some 
> state to be 
> > Looking for a good middle ground to essentially describe the case 
> > where one side of the call doesn't have to do anything 
> special outside 
> > of supporting widely implemented protocol primitives (I 
> know, slippery 
> > ground).
> > 
> > understand a particular feature that it does not claim support for. 
> > For example, the non-initiator may not support consultative call 
> > transfer, but it does support REFER. To the initiator of a 
> > consultative call transfer feature that uses only 
> primitives such as 
> > REFER, the feature appears to work even though the non-initiator 
> > wasn't doing anything specific to that feature: it's single-ended.
> >

---

From: [email-masked]
Date: Tue, 24 Jul 2007 17:28:01 -0400

From: Jonathan Rosenberg <[email-masked]>

I think that should be "the other end of the dialog" rather than
"other participants".  Under that definition, any feature provided on
behalf of the UA by a proxy that has an ongoing relationship with the
UA is "single-ended".

There aren't many of those now (in plain SIP), but there are likely to
be more in the future.  Consider DND processing performed by "the
proxy" on behalf of the UA.

And there really is value is standardizing the interaction between the
UA and the supporting proxy for single-ended features.

Dale