Subject: RE: [Sip] re: the future of call control

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 3 Dec 2001 11:56:00 -0500

Comments are inline [RRR].

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 03, 2001 9:38 AM
To: [email-masked]
Subject: Re: [Sip] re: the future of call control

>   >, the
>   >question can be "Does your product comply with H.323, H.225, H.425, and
>   >H450.2 for Call Transfer?" If anyone tries to sell SIP phones for use
in 
real
>   >networks, what would the equivalent question be for compliance?
>  
>  What you are talking about standardizing is basically user interface 
>  dependent.  who gets to define the interface for call park?  This isn't 
>  consistent on Centrex services with analog phones, and it isn't
consistent 
>  across PBX and key systems.
>  
I ceratainly agree that we would not be standardizing the user interface. As

in all other telecommunications standards activities, the "network
interface" 
needs to be standardized. Many of the examples drawn have included 
interactions with a Proxy. This interface can not be proprietary. 

[RRR] This is a very important point that Mike has mentioned. I can extend
the example to interfaces of SIP proxies to location servers, policy
servers, security servers, and many others.

If some services work without the intervention of a Proxy (direct
user-to-user 
messages), then they should be easy to standardize, but it still must be
done 
in order to define the interaction of these simple services with those that 
require the use of a Proxy. Otherwise, we can't be sure that "blind
transfer" 
will work correctly with, say, Call Forwarding on No Answer.

[RRR] I agree with Mike that the interactions of proxies to provide services
are also very important and, standard interfaces need to be developed
especially for service providers to execute and create network-based
services. My hope is that we will be moving in that direction (e.g., CPL,
SIP services examples, etc. are just the start). In any event, SIP call
services are very important for standardization (e.g., functional
requirements, new SIP primitives if any, RFCs for SIP call services,
interfaces, etc.).

>  thanks,
>  -rohan
Mike

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Eric Burger" <[email-masked]>
Date: Sat, 8 Dec 2001 21:45:27 -0500

I fully *disagree* that these services need to be standardized.  The reason
is simple: what we're being asked to do is standardize a "marketing"
function.  What do I mean by that?  You want to advertise that you support
"blind transfer".  I can think of at least two, orthogonal ways of
implementing it.  Standardizing the call flow for blind transfer means that
any of the other, legitimate, possibly superior methods can't be "legally"
used.

What we *must* standardize are the primitives to implement such functions.

Yes - we need to know about blind transfer, consultation transfer,
consultation hold, music while parked, and walking fifi [sic] to decide that
we need one or more primitives.  In addition, I agree that it would be
informative to show *typical* call flows demonstrating the use of those
primitives.  This is all in the realm of the SIPPING work group.  Once the
need for the PRIMITIVE is determined, then the primitive development can go
on in the SIP work group.

What about interoperation?  Clearly, you want to advertise that in order for
YOUR UA to do transfer, the TARGET UA/Proxy/foo would have to implement the
necessary primitives properly.  However, I strongly disagree that you have
to codify the detailed call flow.  Either the primitive does what it is
supposed to do or it does not.  The exact call flow (order of primitive
execution) should not matter - YOUR UA is in control of the dialog!

Note that I take this stand not for the "IETF Doesn't Like Things Like
H.450.1, H.450.2, H.450.99999" reason, although it is somewhat reasonable as
a design approach.  For that matter, I do see the need for some level of
standardization of practice, as evidenced by draft-burger-sipping-msuri-01.
However, I do NOT think that the IETF is the place for reducing the practice
of a given call control method to a RFC.

If you do believe you need "standards" for such interoperation, I can think
of three organizations you can bring it to: 3GPP for wireless, CableLabs for
Broadband, and ISC for wireline.  Note that 3GPP and ISC explicitly state
they won't add or change SIP as defined by the IETF.  Documenting a call
flow doesn't change SIP :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Roy,
Radhika R, ALCTA
Sent: Monday, December 03, 2001 11:56 AM
To: [email-masked]; [email-masked]
Subject: RE: [Sip] re: the future of call control

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 03, 2001 9:38 AM
To: [email-masked]
Subject: Re: [Sip] re: the future of call control

in
real
consistent

Mike