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

From: Xiaotao Wu <[email-masked]>
Date: Thu, 10 Mar 2005 14:06:28 -0500 (EST)

On Thu, 10 Mar 2005, Seamus Gilchrist wrote:

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

Sorry, I did not make my points clear.

I stated that 'putting services in the network if possible'. It is
confusing about the meaning of the word 'possible'. I did not mean
to have network servers to control endpoints, e.g., by MGCP or H248.
Instead, the 'possible' situation is under the VoIP architecture, with
endpoints and network servers as equal entities (no master-slave
relationship between them). So, for CF services, it is possible to put
them in the network, unless users want to check locally stored
addressbook to make call decisions.

Thanks!

-Xiaotao

>
> 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...
>
>
> On Thu, 10 Mar 2005, Michael Hammer (mhammer) wrote:
>
> > Mike,
> >
> > I disagree with your statement that services such as Call Forwarding No
> > 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
>
> >
> > 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
>

_______________________________________________
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: David R Oran <[email-masked]>
Date: Thu, 10 Mar 2005 14:54:11 -0500

> addressbook to make call decisions.
In my usual and unfortunately blunt manner, let me observe that this is 
a fundamentally useless and silly discussion. Why?

Because a proxy has no idea if the next SIP hop element is another 
proxy, a UAS, or a B2BUA.

The whole notion of "in the network" is slippery and fairly useless in 
an Internet environment. You may wish to ask the Asterisk process on my 
home Linux server is it is "in the network" or not. (Actually, don't 
bother - it doesn't know).

The specific case of call forwarding is a particularly bad one, because 
SIP doesn't do call forwarding. It does redirection and retargeting.

Those map onto many flavors of "call forwarding", some of whose 
instances map onto what the legacy systems call "call forwarding" and 
some of which do not.

Dave.

>>> a trivial matter to specify.
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Xiaotao Wu <[email-masked]>
Date: Thu, 10 Mar 2005 18:25:34 -0500 (EST)

> proxy, a UAS, or a B2BUA.

Why a proxy has to know the type of its next SIP hop element for services?
It's people to decide where to put services. You cannot put the same
services everywhere.

> bother - it doesn't know).

Most people will not host a home-based SIP server.

One fundamental difference between endpoints and network servers in a SIP
architecture is that SIP endpoints directly manipulate media streams, but
network servers usually not (except some services, like transcoding and
anonymizing). If you do not use your Linux box as a UA, it is 'in the
network', even though you host it in your home.

> SIP doesn't do call forwarding. It does redirection and retargeting.

It does not matter you name it 'redirection', 'retargeting', or 'call
forwarding'. The thing is, for this kind of routing services, it's better
not to put it in endpoints. Certainly, endpoints can do a lot of things,
but it's better not to let endpoints do all what they can do.

Thanks!

-Xiaotao