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

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Thu, 10 Mar 2005 12:02:55 -0500

Mike,
 
I disagree with your statement that services such as Call Forwarding No
Answer MUST be done in a proxy.  Two cases exist:
 
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.
 
Note that the correct 3xx is not defined yet (use 380?), but that should
a trivial matter to specify.
 
Mike H.

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Wednesday, March 09, 2005 5:55 PM
	To: [email-masked]; [email-masked]
	Cc: [email-masked]; [email-masked]
	Subject: Re: feature interaction,was: Re: [Sipping] draft on SIP
architectural princi...

	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: Xiaotao Wu <[email-masked]>
Date: Thu, 10 Mar 2005 13:06:38 -0500 (EST)

> Answer MUST be done in a proxy.  Two cases exist:

Mike H.,

I agree that CF does not have to be done in a proxy.

I think we'd better category services are services in endpoints and
services in the network. Using Proxy or using method 2) in your email are
in fact both services in the network. But 1) is in an endpoint.

Many services can be in both endpoints and network, like the CF service.
However, I think the rule is always to put services in the network if
possible, given that network servers are usually always on, and better
maintained. Unless people have other concerns, like privacy, cost, or
there is no service infra-structure, like in a P2P network. Also,
we need to keep service implementations as easy as possible.

For Call Forwarding No Answer, even though it can be done in endpoints,
or proxy servers, or application servers, the best way is to put it on a
proxy server.

Thanks!

-Xiaotao

---

From: "Seamus Gilchrist" <[email-masked]>
Date: Thu, 10 Mar 2005 13:20:17 -0500

Xiaotao,

It seems that saying that the general rule is that services should be in the
network is in violation of the spirit of the work (3.2 of the sipping arch)
and puts us back in the direction of the PSTN. 

Regards,

Seamus

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Xiaotao Wu
Sent: Thursday, March 10, 2005 1:07 PM
To: Michael Hammer (mhammer)
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: RE: feature interaction, was: Re: [Sipping] draft on SIP
architecturalprinci...

Mike H.,

Thanks!

-Xiaotao