[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Comments are inline [RRR]. By the way, I do not see any disagreement.

-----Original Message-----
From: Eric Burger [mailto:eburger@snowshore.com]
Sent: Saturday, December 08, 2001 9:45 PM
To: Roy, Radhika R, ALCTA; Mpierce1@aol.com
Cc: sip@ietf.org
Subject: RE: [Sip] re: the future of call control


I fully *disagree* that these services need to be standardized.  

[RRR] We all agreed that services must NOT be standardized. Let us close this issue.

The reason
is simple: what we're being asked to do is standardize a "marketing"
function.  What do I mean by that?  ....

[RRR] Without going through any more examples, let us take the example of the SIP Call Transfer draft. It will be an RFC and will provide the guidelines for implementation of the call transfer in SIP. 

[RRR] Primitives must be standardized. (By the way, the REFER primitive in SIP came out of this call transfer draft.)

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

[RRR] We all agreed earlier that primitives must be standardized. (By the way, the REFER primitive in SIP came out of this call transfer draft.)

...

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.

[RRR] SIP call transfer draft, as SIP/SIPPING WG intends, will be an RFC. That is what people want to do in the IETF in addition to the standardization of the SIP primitives.

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 :-)

[RRR] This is called interoperability among multi-vendor or multi-networking environment for implementation of a given standard and, there are many forums available throughout the world. (IETF is not working in this area).


_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip