Proposal to support AMR codec in H.245 using RFC3267

Tue Jan 25 17:16:16 EST 2005

Hi,

Please see in line.....

Look for vnanduri

At 03:47 PM 1/25/2005 +0200, ari.lakaniemi at nokia.com wrote:
>hello Venkata,
>
>Thanks for preparing the document.
>
>I have more or less the same comment as Roni Even already made:
>There seems to be no parameters for controlling the "crc" and 
>"robust-sorting" options available in RFC 3267. Are these options somehow

>problematic in the scope of H.245?

<vnanduri>

In-order to apply CRC, interleaving and robust-sorting , frame format
shall 
be octet aligned.
Since there is a dependency among different parameters, octetAlign 
parameter is defined in
H245 which also handles CRC and robust-sorting. May be I need to rename 
this octetAlign
parameter to something that is meaningful for octetAlign, CRC and 
robust-sorting (Any suggestions??)
The presence of octetAlign parameter itself indicates octet aligned frame 
format.

The octetAlign parameter is defined as booleanArray to take care of CRC
and 
robust-sorting
values. Bit 0 is used for CRC and Bit 1 for robust-sorting.

But, interleaving can also be only applied if the frame format is 
octet-aligned and the value for
interleaving is number of frame blocks which cannot be defined as part of 
booleanArray. So, a
new parameter is defined. Interleaving parameter shall be absent if 
octetAlign parameter is absent.

The main intention of consolidating the parameters is to minimize the bits

that will be transmitted
across the wire...

>Another question is about the definition of the capability parameter
modeSet.
>Currently the draft specifies that
>
>  "... If present, specifies the subset of modes available for current 
> session. If absent, no modes are supported."
>
>However, in RFC 3267 the definition of the corresponding MIME parameter
says
>  "... If not present, all codec modes are allowed for the session."
>
>Maybe it would be clearer to use the same interpretation as in RFC 3267
in 
>case the paramter modeSet is not present?

<vnanduri>

For some of the parameters defined in RFC3267, similar parameters are 
defined with a different interpretation in H.245
to take care of conference scenarios.

Please look below for details about why they are defined differently in
H.245:

1) octet-align(SDP) -------->octetAlign--booleanArray (also accommodates 
crc and robust-sorting)(H.245)

described above

2) mode-set(SDP) ---------->modeSet and modeSetExtended. modeSetExtended
is 
used only AMR-WB(H245)

modeSet is defined as booleanArray which can accommodate only 8 boolean 
values. Since AMR-NB has only
8 bit rates, modeSet parameter will be sufficient for AMR-NB. How ever, 
since AMR-WB has 9 modes, first
8 modes will be accommodated in modeSet parameter and 9th mode will be 
accommodated in
modeSetExtended parameter.

Suppose an MC that is not aware of AMR codec capability, gets this 
capability from three endpoints A, B and C
and wants to create a common capability description.  Suppose A sends no 
modeSet, B sends a modeSet with
10000011 and C sends a modeSet with 10000001. Now, a common capability 
description should contain the
modeSet as 10000001. But the MC has to ignore those parameters that are
not 
supported by all endpoints.

So the MC will send out a cap description without a modeSet, which will 
imply support for all modes, which is not
the expected behavior. So, absence of this parameter is defined as lack of

support of any modes.

The same comment applies for modeSetExtended - the absence of the
parameter 
should indicate lack of support for
the 9th mode,  and this parameter should be present if the 9th mode is 
supported.

3) mode-change-period(SDP) ----->modeChangePeriod(H245).

For modeChangePeriod, for example, if A sent a period of 5, B sent 3 and C

did not
send anything, the common cap description prepared by the MC will not
contain a
modeChangePeriod. So A, which could only change modes once in 5 frames
will
now receive audio that may changes mode at every frame which is not the 
expected
behavior. Hence, this parameter is made mandatory and is defined as
unsignedMax
which indicates to MC that it has to select the largest value it receives 
from different
end points. With this definition in H.245   Now, C has to send 0 as the
value,
and MC will select 5 which is the appropriate value.

4) mode-change-neighbor(SDP) -----> modeChangeAll(H245)

For example, if A did not send, B sent with value 1, C sent value of 0,

Again, an MC that does not include the value because one endpoint did not 
include.
It will be creating a common capability description that indicates 
permission to
switch to any mode(absence of param from A or a value 0 from C).  Again 
this is not
the expected behavior.

So, this parameter is defined as 'ModeChangeAll'. The presence of this 
parameter
means 'change from any to any mode is permitted'. Then if a combining MC 
creates
a cap description that does not have ModeChangeAll (because one endpoint 
did not send it),
it will be correctly forcing all endpoints to the common subset which is 
change to neighboring
modes only is permitted'.

5) maxptime(SDP) ----------> alAduFrames(H.245)
6) ptime(DSP)-------> alAduFrames(H245)

numFrames parameter will correspond to the value for maxptime when used in
TCS messages and will correspond to value for ptime when used in OLC and
MR
messages.

7) crc(SDP) -----------> octetAlign(H.245)

described above

8) robust-sorting(SDP) ------> octetAlign(H.245)

described above

9) interleaving(SDP) -----> interleaving(H.245)

described above

10) channels(SDP) -----> numChannels(H245)

Same as SDP

Please let me know if you have any other questions...

Thanks
Venkata

>BR,
>Ari Lakaniemi
>Nokia Research Center
>
> > -----Original Message-----
> > From: ext Even, Roni [mailto:roni.even at polycom.co.il]
> > Sent: 25 January, 2005 10:10
> > To: Venkata Nanduri; itu-sg16 at external.cisco.com; Lakaniemi Ari
> > (Nokia-NRC/Helsinki)
> > Subject: RE: Proposal to support AMR codec in H.245 using RFC3267
> >
> >
> > Hi,
> > I just scanned through the draft. I noticed that there is no full
> > mapping of the SDP parameters from RFC3267 to generic parameters. Is
> > there a reason for the difference.
> > I think that there should be some text that will explain the
> > relationship to H.245 annex I.
> > Roni Even
> >
> > -----Original Message-----
> > From: Venkata Nanduri [mailto:vnanduri at cisco.com]
> > Sent: Tuesday, January 25, 2005 12:33 AM
> > To: itu-sg16 at external.cisco.com; ari.lakaniemi at NOKIA.COM
> > Cc: vnanduri at cisco.com
> > Subject: Proposal to support AMR codec in H.245 using RFC3267
> >
> > Dear SG16 experts,
> >
> > I would like the attached proposal to be submitted to next meeting of
> > SG16
> > group to be held at
> > Melbourne in February last week, 2005.
> >
> > Before I submit the proposal formally, I would like to get some early
> > feedback on the proposal
> > from experts in the group.
> >
> > Can you please review the document and let me know your comments?
> >
> > Thanks
> > Venkata
> >
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 12210 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20050125/6c125bac/attachment-0004.bin>