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

From: [email-masked]
Date: Wed, 9 Mar 2005 17:54:40 EST

In a message dated 3/8/2005 6:15:39 PM Central Standard Time, 
[email-masked] writes:

> In that sense, feature interaction it is probably more a problem of 
> enabling the negotiation of features between the entities in a call than 
> defining a table that says "features X doesn't work with feature Y". 
> Needless to say, that such a mechanism that covers all entities in a 
> call seems to be a very complex thing...
> 

Absolutely. That's why I've come to the conclusion that all features for 
which there is a required interaction must be controlled by one device. One of 
that set of features is Call Forwarding No Answer. As shown in 
draft-ietf-sipping-service-examples-08 this needs to be controlled by a proxy.

(Before anyone comments, yes, I know this draft is intended to be 
"informative", not "standards track" and is only intended to give "examples" of how these 
services can be done, but I haven't seen any other way described.)

The bottom line is that several (many?) services must be controlled by such a 
proxy as shown in draft-ietf-sipping-service-examples-08. Even if some 
individual services could be defined to work without a proxy (like Auto redial as 
shown in 2.18), since it must interact with proxy-controlled services in certain 
ways, it too must be proxy-controlled.

Mike Pierce
_______________________________________________
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: Sun, 13 Mar 2005 13:02:13 EST

In a message dated 3/10/2005 11:03:38 AM Central Standard Time, 
[email-masked] writes:

> 1) UAS (Bob) is online, but doesn't answer:  A 3xx type response could be 
> delivered to the UAC (Alice) saying in effect, I am not available, try calling 
> alternate UAS (Charlie) instead.
>  
> 2) UAS (Bob) is disconnected, e.g. out of radio coverage:  An always online 
> application server (operated by your friendly ITSP) hosting an automaton 
> (logical terminal) for Bob could register a Contact with the Proxy.  An INVITE to 
> a Proxy gets forked to both B1 (Bob's terminal) and to B2 (Bob's automaton). 
>  In this case, Bob's regular terminal device does not respond but the 
> automaton returns a 3xx response as above based on Bob's policy (ToD, Caller ID, 
> etc.) or accepts the call and takes a voice-mail.  After the proxy does not see 
> any response from B1, it forwards the 3xx from B2 to Alice.  Alice, after 
> she is notified of the forwarding, she knows the call is going to Charlie and 
> decides to allow the forwarding to proceed (does not hang up), her terminal 
> initiates a new call to Charlie.  If for some reason, Charlie needs to be 
> anonymous, then an anonymous address that routes to Charlie should be used in 
> Bob's forwarding service.
>  
> In either case, it is not the proxy that does the re-targeting of the call, 
> i.e. the call forwarding, since according to the SIP principles, proxies only 
> route.
> 

Case #1 is not acceptable since, if Bob's terminal doesn't respond, Call 
Forwarding No Answer doesn't happen.

Case #2 is interesting, if you think "forking" is an answer to the problem. 
Is this specific example described above documented anywhere? Besides, in your 
description, the knowledge that Call Forwarding No Answer applies to this call 
is not in the end device as I said. Where is it? Isn't it in a proxy? Or is 
it in a box that you've given a different name than "proxy"? If I compare this 
procedure with the procedure for a call that does not have Call Forwarding No 
Answer active, where is the decision between the two procedures made? Where is 
the decision to fork or not to fork?

You have, in fact, described a procedure in which the proxy does the Call 
Forwarding, only you've described it with a separate "logical terminal" B2 that 
does the timing. Where and what is that "logical terminal" B2? It's not a 
physical device. I believe it's physically part of the proxy, so the proxy actually 
performs the whole Call Forwarding No Answer service as I said.

Or the "logical terminal" B2 is part of a separate "application server". That 
must mean that every call setup attempt goes to that "application server". So 
all services are done there, not in the end device. Then I need to revise my 
statement. The service doesn't have to be done in a device everyone calls a 
"proxy". But it must be done in a network element, whether it's a proxy, 
application server, or something else. I don't really care what it's called in the 
SIP model. But it's in the network and operated by the service provider.

I'm simply going by what has been documented in 
draft-ietf-sipping-service-examples-08 on ways to actually do various services. If there is any other way 
that works, I'd like to see it detailed out as in that draft.

Mike

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 14 Mar 2005 20:30:10 -0500

Mike P.
 
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.
 
Mike

________________________________

	From: [email-masked] [mailto:[email-masked]] 
	Sent: Sunday, March 13, 2005 1:02 PM
	To: Michael Hammer (mhammer); [email-masked];
[email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Re: feature interaction,was: Re: [Sipping] draft on SIP
architectural princi...

	

		1) UAS (Bob) is online, but doesn't answer:  A 3xx type
response could be delivered to the UAC (Alice) saying in effect, I am
not available, try calling alternate UAS (Charlie) instead.
		
		2) UAS (Bob) is disconnected, e.g. out of radio
coverage:  An always online application server (operated by your
friendly ITSP) hosting an automaton (logical terminal) for Bob could
register a Contact with the Proxy.  An INVITE to a Proxy gets forked to
both B1 (Bob's terminal) and to B2 (Bob's automaton).  In this case,
Bob's regular terminal device does not respond but the automaton returns
a 3xx response as above based on Bob's policy (ToD, Caller ID, etc.) or
accepts the call and takes a voice-mail.  After the proxy does not see
any response from B1, it forwards the 3xx from B2 to Alice.  Alice,
after she is notified of the forwarding, she knows the call is going to
Charlie and decides to allow the forwarding to proceed (does not hang
up), her terminal initiates a new call to Charlie.  If for some reason,
Charlie needs to be anonymous, then an anonymous address that routes to
Charlie should be used in Bob's forwarding service.
		
		In either case, it is not the proxy that does the
re-targeting of the call, i.e. the call forwarding, since according to
the SIP principles, proxies only route.

	Case #1 is not acceptable since, if Bob's terminal doesn't
respond, Call Forwarding No Answer doesn't happen.
	
	Case #2 is interesting, if you think "forking" is an answer to
the problem. Is this specific example described above documented
anywhere? Besides, in your description, the knowledge that Call
Forwarding No Answer applies to this call is not in the end device as I
said. Where is it? Isn't it in a proxy? Or is it in a box that you've
given a different name than "proxy"? If I compare this procedure with
the procedure for a call that does not have Call Forwarding No Answer
active, where is the decision between the two procedures made? Where is
the decision to fork or not to fork?
	
	You have, in fact, described a procedure in which the proxy does
the Call Forwarding, only you've described it with a separate "logical
terminal" B2 that does the timing. Where and what is that "logical
terminal" B2? It's not a physical device. I believe it's physically part
of the proxy, so the proxy actually performs the whole Call Forwarding
No Answer service as I said.
	
	Or the "logical terminal" B2 is part of a separate "application
server". That must mean that every call setup attempt goes to that
"application server". So all services are done there, not in the end
device. Then I need to revise my statement. The service doesn't have to
be done in a device everyone calls a "proxy". But it must be done in a
network element, whether it's a proxy, application server, or something
else. I don't really care what it's called in the SIP model. But it's in
the network and operated by the service provider.
	
	I'm simply going by what has been documented in
draft-ietf-sipping-service-examples-08 on ways to actually do various
services. If there is any other way that works, I'd like to see it
detailed out as in that draft.
	
	Mike

---

From: [email-masked]
Date: Fri, 18 Mar 2005 08:44:26 EST

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

> 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.