I-D ACTION:draft-ietf-megaco-ipphone-02.txt

Rosen, Brian brosen at FORE.COM
Fri Mar 3 13:21:53 EST 2000


Matt

The protocol states MGCs SHOULD support both.  That is not
a requirement.

The purpose of a profile is to narrow down the breadth that the
protocol specifies so that you can plug an MG into an MGC and you
KNOW that they will play.  This is generally NOT the case with
a random MG plugging into a random MGC - there are lots and lots
of things that would make them not compatible, and still both
be conformant to the protocol.

For each and every option possible in the protocol, a well defined
profile should specify a minimum requirement.  A conformant
device should be able to go above the minimum.  This means in
every profile, a choice will be made on encoding.  If this is
not done, then a customer cannot tell by comparing the profile
of an MG whether it will be compatible with his MGC.  He should
absolutely be able to do this.

In this case, if an MGC advertises that it conforms to the IPPhone
profile, but does not support text encoding, it is not out
of compliance with either the protocol or the profile.  If you
try to plug a binary-only IPPhone into such a system, it won't
work.  That is, in my opinion, unacceptable.

I will even go so far as to say that the minimum is also the
preferred - even if the device can do more, the point of a profile
is to specify a set of option choices that will allow 100%
compatibility.  If you have a device that REQUIRES some profile x
PLUS some feature y, then it would be better to define a new
profile as being an extension of x to include y.

Brian

> -----Original Message-----
> From: Matt Holdrege [mailto:holdrege at lucent.com]
> Sent: Friday, March 03, 2000 12:56 PM
> To: Rosen, Brian
> Cc: ITU-SG16 at mailbag.cps.INTEL.COM
> Subject: Re: I-D ACTION:draft-ietf-megaco-ipphone-02.txt
>
>
> If MGC's must support both text and binary, what does it hurt
> to allow IP
> phones to do either?
>



More information about the sg16-avd mailing list