Hi,
Please see on line....
At 09:58 AM 1/26/2005 +0200, ari.lakaniemi(a)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(a)polycom.co.il; itu-sg16(a)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
>
> At 03:47 PM 1/25/2005 +0200, ari.lakaniemi(a)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@polycom.co.il]
> > > Sent: 25 January, 2005 10:10
> > > To: Venkata Nanduri; itu-sg16(a)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(a)external.cisco.com; ari.lakaniemi(a)NOKIA.COM
> > > Cc: vnanduri(a)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
> > >
>
