Subject: RE: feature interaction, was: Re: [Sipping] draft on SIP architectural princi...

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 28 Mar 2005 17:22:05 -0500

Actually, we are disagreeing over what it means to be "in the network".
A data-centric view would say that the routers are the network and all
other boxes are end hosts.  For a voice-centric view, there are UAs at
the edge and Proxies "in the network."  I was simply posing that the
service could be provided by an application server UA, which could be
operated by a service provider on behalf of end-users or by a clueful
end-user, e.g. an always-on PC, and be consistent with native SIP
approaches to designing services.  You are free to have the App server
operated by the service provider and call it "in the network".
 
The bottom line for "doing the service" is whether Alice's call gets
forwarded to the number Bob setup as an alternate in case he doesn't
answer.  My response does that.  The fact that Alice is also aware of
the forwarding and can react to it is simply an added benefit.  Don't
get too hung up on that aspect.
 
As for feature interactions, the half-call model was all about having
the respective features serve their respective sole masters.  A conflict
between your feature and mine is not necessarily a bug, but may be a
service to me.  The real "feature interaction" problem was internal to
one side of the half-call, e.g. one of Alice's features blocking another
of Alice's features.
 
Mike H.

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Friday, March 18, 2005 8:44 AM
	To: Michael Hammer (mhammer); [email-masked];
[email-masked]
	Cc: [email-masked]
	Subject: Re: feature interaction, was: Re: [Sipping] draft on
SIP architectural princi...

	In a message dated 3/14/2005 8:33:29 PM Eastern Standard Time,
[email-masked] writes:

		The example I posed is not in the services draft.  The
message flows are different, but achieve the same end.  The major
difference is that the proxy sticks to doing only routing and endpoints
do the services.  Whether you bundle the B2 application server endpoint
with the proxy function in the same network box is an implementation
detail.   But, there is an external difference in the message flows
observed by Alice and in how Alice can opt to continue or discontinue
participation.

	I guess we have a very different idea of what "doing the
services" in an endpoint means. As I understand your example, an
application server knows that some end user wants Call Forwarding No
Answer and some device other than the user's endpoint decides to "fork"
the invite to the "automaton" (B2). That "automaton" is not in the
user's endpoint. The "automaton" applies the timeout and then does
something to cause the call to be sent to the forwarded-to party. The
user's endpoint did not "do" the service. It knew nothing about it. (I'm
talking about the user who wants the Call Forwarding No Answer service -
Bob.)
	
	I completely fail to see how you can say that the "endpoints do
the service", unless you're referring to the "fictional" endpoint B2.
Since it's "hosted by the application server" as you described, it's not
the user's endpoint, which is the only issue. It is part of the
application server, whether you model it as a "B2BUA" or whatever. The
service is being "done" in the network.
	
	Or you're actually referring to what Alice's endpoint does in
support of the actual protocol for Call Forwarding (sending the new
INVITE). This wasn't the issue. My comments have to do with the B side
user vs. a network element controlling the service. The originating side
(endpoint) can't control it even though it might have to do some
protocol action.
	
	Sure, one could try to define a scheme in which Alice's device
blocks the Call Forwarding action by not doing what it was told to do,
but that is a different service, not the one under discussion. This is
in fact part of the original question posed - how to manage interactions
between two different services, in this case, one provided by the
network (for the called party) and one performed by the calling party's
terminal.
	
	Mike P.

_______________________________________________
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: [email-masked]
Date: Mon, 28 Mar 2005 17:07:22 -0600

An interesting wrinkle to the "in the network" discussion is that SIP is
also a peer-to-peer protocol, besides the trapezoid model exemplified in RFC
3261.

Recent work on P2P SIP is a good reminder that the "Network SIP Services"
can be omitted and the question is not if but how:

http://www.ietf.org/internet-drafts/draft-johnston-sipping-p2p-ipcom-01.txt 

Actually, most useful functions in SIP can be done peer-to-peer and the
framework on Call Control is a good starting point:

http://www.softarmor.com/wgdb/docs/draft-mahy-sip-cc-models-00.txt 

Thanks, Henry

  _____  

From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Monday, March 28, 2005 4:22 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: feature interaction,was: Re: [Sipping] draft on SIP
architectural princi...

Actually, we are disagreeing over what it means to be "in the network".  A
data-centric view would say that the routers are the network and all other
boxes are end hosts.  For a voice-centric view, there are UAs at the edge
and Proxies "in the network."  I was simply posing that the service could be
provided by an application server UA, which could be operated by a service
provider on behalf of end-users or by a clueful end-user, e.g. an always-on
PC, and be consistent with native SIP approaches to designing services.  You
are free to have the App server operated by the service provider and call it
"in the network".

The bottom line for "doing the service" is whether Alice's call gets
forwarded to the number Bob setup as an alternate in case he doesn't answer.
My response does that.  The fact that Alice is also aware of the forwarding
and can react to it is simply an added benefit.  Don't get too hung up on
that aspect.

As for feature interactions, the half-call model was all about having the
respective features serve their respective sole masters.  A conflict between
your feature and mine is not necessarily a bug, but may be a service to me.
The real "feature interaction" problem was internal to one side of the
half-call, e.g. one of Alice's features blocking another of Alice's
features.

Mike H.

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, March 18, 2005 8:44 AM
To: Michael Hammer (mhammer); [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: feature interaction, was: Re: [Sipping] draft on SIP
architectural princi...

The example I posed is not in the services draft.  The message flows are
different, but achieve the same end.  The major difference is that the proxy
sticks to doing only routing and endpoints do the services.  Whether you
bundle the B2 application server endpoint with the proxy function in the
same network box is an implementation detail.   But, there is an external
difference in the message flows observed by Alice and in how Alice can opt
to continue or discontinue participation.

I guess we have a very different idea of what "doing the services" in an
endpoint means. As I understand your example, an application server knows
that some end user wants Call Forwarding No Answer and some device other
than the user's endpoint decides to "fork" the invite to the "automaton"
(B2). That "automaton" is not in the user's endpoint. The "automaton"
applies the timeout and then does something to cause the call to be sent to
the forwarded-to party. The user's endpoint did not "do" the service. It
knew nothing about it. (I'm talking about the user who wants the Call
Forwarding No Answer service - Bob.)

I completely fail to see how you can say that the "endpoints do the
service", unless you're referring to the "fictional" endpoint B2. Since it's
"hosted by the application server" as you described, it's not the user's
endpoint, which is the only issue. It is part of the application server,
whether you model it as a "B2BUA" or whatever. The service is being "done"
in the network.

Or you're actually referring to what Alice's endpoint does in support of the
actual protocol for Call Forwarding (sending the new INVITE). This wasn't
the issue. My comments have to do with the B side user vs. a network element
controlling the service. The originating side (endpoint) can't control it
even though it might have to do some protocol action.

Sure, one could try to define a scheme in which Alice's device blocks the
Call Forwarding action by not doing what it was told to do, but that is a
different service, not the one under discussion. This is in fact part of the
original question posed - how to manage interactions between two different
services, in this case, one provided by the network (for the called party)
and one performed by the calling party's terminal.

Mike P.