Hi,
Please see on line....
At 09:58 AM 1/26/2005 +0200, ari.lakaniemi@nokia.com wrote:
hello Venkata,
Thanks for the explanations. It seems that I was not reading thoroughly
enough since I missed the CRC and robust-sorting features incorporated
into the octetAlign parameter.
Some furhter comments below.
modeSet:
OK, I can see the reasoning behind the modeSet definition as it is written
in your draft. However, since absence of modeSet would mean a session
without any allowed modes, wouldn't it make sense to make this parameter
mandatory?
<vnanduri> This parameter can be made mandatory.
(Note also that in RFC 3267 the parameter mode-set is introduced only to
enable connections (through a gateway) to GSM networks, which can only
support mode-sets of up to 4 AMR modes. I think in 'normal' VoIP usage the
full set of AMR modes should be supported.)
<vnanduri> I think RFC3267 does not mention about the restrictions
mentioned above. If so, can you please point me to the section?
modeChangePeriod:
This is also something that is defined in RFC 3267 only for interopreation
with GSM (where the signaling is limited in such a way that mode changes
are restricted to happen in 2-frame intervals). Thus, I think other values
than (1 or) 2 are not meaningful in practice. I do not know if this
document would be a right place to include an informational note about
this...
There is actually an identified problem regarding this in RFC 3267: does
the parameter mode-change-period indicate sender's capability to send
(also) using mode-change-period=2 (since the AMR _codec_ does not have
such limitation) or receiver's capability to _only_ receive using
mode-change-period=2? We are currently preapring an update for RFC 3267
(which will be eventually published with different RFC number) to clarify
this (among some other things).
<vnanduri> I think RFC3267 does not mention about the restrictions
mentioned above. If so, can you please point me to the section?
On Internet I could find ietf-avt-rtp-amr-bis-00.txt. But, that may not be
the latest.
Can you please send me the latest draft that is in progress(updated
rfc3267)?
Thanks
Venkata
br,
Ari
-----Original Message-----
From: ext Venkata Nanduri [mailto:vnanduri@cisco.com]
Sent: 26 January, 2005 00:16
To: Lakaniemi Ari (Nokia-NRC/Helsinki)
Cc: roni.even@polycom.co.il; itu-sg16@external.cisco.com;
Hagqvist Jari
(Nokia-NRC/Tampere)
Subject: RE: Proposal to support AMR codec in H.245 using RFC3267
Importance: High
Hi,
Please see in line.....
Look for vnanduri
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
At 03:47 PM 1/25/2005 +0200, ari.lakaniemi@nokia.com wrote:
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@polycom.co.il]
Sent: 25 January, 2005 10:10
To: Venkata Nanduri; itu-sg16@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@cisco.com]
Sent: Tuesday, January 25, 2005 12:33 AM
To: itu-sg16@external.cisco.com; ari.lakaniemi@NOKIA.COM
Cc: vnanduri@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