<html>
Hi,<br>
<br>
Please see on line....<br>
<br>
At 09:58 AM 1/26/2005 +0200, ari.lakaniemi@nokia.com wrote:<br>
<blockquote type=cite cite>hello Venkata,<br>
<br>
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.<br>
<br>
Some furhter comments below.<br>
<br>
modeSet:<br>
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?</blockquote><br>
<vnanduri> This parameter can be made mandatory. <br>
<br>
<blockquote type=cite cite>(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.)<br>
</blockquote><br>
<vnanduri> I think RFC3267 does not mention about the restrictions
mentioned above. If so, can you please point me to the section?<br>
<br>
<br>
<br>
<blockquote type=cite cite>modeChangePeriod:<br>
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...<br>
<br>
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).</blockquote><br>
<br>
<vnanduri> I think RFC3267 does not mention about the restrictions
mentioned above. If so, can you please point me to the section?<br>
<br>
On Internet I could find <b>ietf-avt-rtp-amr-bis-00.txt. </b> But, that
may not be the latest.<br>
Can you please send me the latest draft that is in progress(updated
rfc3267)?<br>
<br>
Thanks<br>
Venkata<br>
<br>
<br>
<br>
<br>
<blockquote type=cite cite>br,<br>
Ari<br>
<br>
> -----Original Message-----<br>
> From: ext Venkata Nanduri
[<a href="mailto:vnanduri@cisco.com" eudora="autourl">mailto:vnanduri@cisco.com</a>]<br>
> Sent: 26 January, 2005 00:16<br>
> To: Lakaniemi Ari (Nokia-NRC/Helsinki)<br>
> Cc: roni.even@polycom.co.il; itu-sg16@external.cisco.com; <br>
> Hagqvist Jari<br>
> (Nokia-NRC/Tampere)<br>
> Subject: RE: Proposal to support AMR codec in H.245 using
RFC3267<br>
> Importance: High<br>
> <br>
> <br>
> Hi,<br>
> <br>
> Please see in line.....<br>
> <br>
> Look for vnanduri<br>
> <br>
> At 03:47 PM 1/25/2005 +0200, ari.lakaniemi@nokia.com wrote:<br>
> >hello Venkata,<br>
> ><br>
> >Thanks for preparing the document.<br>
> ><br>
> >I have more or less the same comment as Roni Even already
made:<br>
> >There seems to be no parameters for controlling the
"crc" and <br>
> >"robust-sorting" options available in RFC 3267. Are
these <br>
> options somehow <br>
> >problematic in the scope of H.245?<br>
> <br>
> <br>
> <vnanduri><br>
> <br>
> In-order to apply CRC, interleaving and robust-sorting , <br>
> frame format shall <br>
> be octet aligned.<br>
> Since there is a dependency among different parameters, octetAlign
<br>
> parameter is defined in<br>
> H245 which also handles CRC and robust-sorting. May be I need <br>
> to rename <br>
> this octetAlign<br>
> parameter to something that is meaningful for octetAlign, CRC and
<br>
> robust-sorting (Any suggestions??)<br>
> The presence of octetAlign parameter itself indicates octet <br>
> aligned frame <br>
> format.<br>
> <br>
> The octetAlign parameter is defined as booleanArray to take <br>
> care of CRC and <br>
> robust-sorting<br>
> values. Bit 0 is used for CRC and Bit 1 for robust-sorting.<br>
> <br>
> But, interleaving can also be only applied if the frame format is
<br>
> octet-aligned and the value for<br>
> interleaving is number of frame blocks which cannot be <br>
> defined as part of <br>
> booleanArray. So, a<br>
> new parameter is defined. Interleaving parameter shall be absent if
<br>
> octetAlign parameter is absent.<br>
> <br>
> The main intention of consolidating the parameters is to <br>
> minimize the bits <br>
> that will be transmitted<br>
> across the wire...<br>
> <br>
> <br>
> >Another question is about the definition of the capability
<br>
> parameter modeSet.<br>
> >Currently the draft specifies that<br>
> ><br>
> > "... If present, specifies the subset of modes
available <br>
> for current <br>
> > session. If absent, no modes are supported."<br>
> ><br>
> >However, in RFC 3267 the definition of the corresponding <br>
> MIME parameter says<br>
> > "... If not present, all codec modes are allowed for
the session."<br>
> ><br>
> >Maybe it would be clearer to use the same interpretation as
<br>
> in RFC 3267 in <br>
> >case the paramter modeSet is not present?<br>
> <br>
> <br>
> <vnanduri><br>
> <br>
> For some of the parameters defined in RFC3267, similar parameters
are <br>
> defined with a different interpretation in H.245<br>
> to take care of conference scenarios.<br>
> <br>
> Please look below for details about why they are defined <br>
> differently in H.245:<br>
> <br>
> <br>
> 1) octet-align(SDP) -------->octetAlign--booleanArray (also
<br>
> accommodates <br>
> crc and robust-sorting)(H.245)<br>
> <br>
> described above<br>
> <br>
> 2) mode-set(SDP) ---------->modeSet and modeSetExtended. <br>
> modeSetExtended is <br>
> used only AMR-WB(H245)<br>
> <br>
> modeSet is defined as booleanArray which can accommodate only <br>
> 8 boolean <br>
> values. Since AMR-NB has only<br>
> 8 bit rates, modeSet parameter will be sufficient for AMR-NB. <br>
> How ever, <br>
> since AMR-WB has 9 modes, first<br>
> 8 modes will be accommodated in modeSet parameter and 9th <br>
> mode will be <br>
> accommodated in<br>
> modeSetExtended parameter.<br>
> <br>
> Suppose an MC that is not aware of AMR codec capability, gets this
<br>
> capability from three endpoints A, B and C<br>
> and wants to create a common capability description. Suppose
<br>
> A sends no <br>
> modeSet, B sends a modeSet with<br>
> 10000011 and C sends a modeSet with 10000001. Now, a common <br>
> capability <br>
> description should contain the<br>
> modeSet as 10000001. But the MC has to ignore those <br>
> parameters that are not <br>
> supported by all endpoints.<br>
> <br>
> So the MC will send out a cap description without a modeSet, <br>
> which will <br>
> imply support for all modes, which is not<br>
> the expected behavior. So, absence of this parameter is <br>
> defined as lack of <br>
> support of any modes.<br>
> <br>
> The same comment applies for modeSetExtended - the absence of <br>
> the parameter <br>
> should indicate lack of support for<br>
> the 9th mode, and this parameter should be present if the
<br>
> 9th mode is <br>
> supported.<br>
> <br>
> 3) mode-change-period(SDP) ----->modeChangePeriod(H245).<br>
> <br>
> For modeChangePeriod, for example, if A sent a period of 5, B <br>
> sent 3 and C <br>
> did not<br>
> send anything, the common cap description prepared by the MC <br>
> will not contain a<br>
> modeChangePeriod. So A, which could only change modes once in <br>
> 5 frames will<br>
> now receive audio that may changes mode at every frame which <br>
> is not the <br>
> expected<br>
> behavior. Hence, this parameter is made mandatory and is <br>
> defined as unsignedMax<br>
> which indicates to MC that it has to select the largest value <br>
> it receives <br>
> from different<br>
> end points. With this definition in H.245 Now, C has to
<br>
> send 0 as the value,<br>
> and MC will select 5 which is the appropriate value.<br>
> <br>
> 4) mode-change-neighbor(SDP) -----> modeChangeAll(H245)<br>
> <br>
> For example, if A did not send, B sent with value 1, C sent <br>
> value of 0,<br>
> <br>
> Again, an MC that does not include the value because one <br>
> endpoint did not <br>
> include.<br>
> It will be creating a common capability description that indicates
<br>
> permission to<br>
> switch to any mode(absence of param from A or a value 0 from <br>
> C). Again <br>
> this is not<br>
> the expected behavior.<br>
> <br>
> So, this parameter is defined as 'ModeChangeAll'. The <br>
> presence of this <br>
> parameter<br>
> means 'change from any to any mode is permitted'. Then if a <br>
> combining MC <br>
> creates<br>
> a cap description that does not have ModeChangeAll (because <br>
> one endpoint <br>
> did not send it),<br>
> it will be correctly forcing all endpoints to the common <br>
> subset which is <br>
> change to neighboring<br>
> modes only is permitted'.<br>
> <br>
> <br>
> 5) maxptime(SDP) ----------> alAduFrames(H.245)<br>
> 6) ptime(DSP)-------> alAduFrames(H245)<br>
> <br>
> numFrames parameter will correspond to the value for maxptime <br>
> when used in<br>
> TCS messages and will correspond to value for ptime when used <br>
> in OLC and MR<br>
> messages.<br>
> <br>
> 7) crc(SDP) -----------> octetAlign(H.245)<br>
> <br>
> described above<br>
> <br>
> 8) robust-sorting(SDP) ------> octetAlign(H.245)<br>
> <br>
> described above<br>
> <br>
> 9) interleaving(SDP) -----> interleaving(H.245)<br>
> <br>
> described above<br>
> <br>
> 10) channels(SDP) -----> numChannels(H245)<br>
> <br>
> Same as SDP<br>
> <br>
> Please let me know if you have any other questions...<br>
> <br>
> Thanks<br>
> Venkata<br>
> <br>
> <br>
> >BR,<br>
> >Ari Lakaniemi<br>
> >Nokia Research Center<br>
> ><br>
> > > -----Original Message-----<br>
> > > From: ext Even, Roni
[<a href="mailto:roni.even@polycom.co.il" eudora="autourl">mailto:roni.even@polycom.co.il</a>]<br>
> > > Sent: 25 January, 2005 10:10<br>
> > > To: Venkata Nanduri; itu-sg16@external.cisco.com;
Lakaniemi Ari<br>
> > > (Nokia-NRC/Helsinki)<br>
> > > Subject: RE: Proposal to support AMR codec in H.245 using
RFC3267<br>
> > ><br>
> > ><br>
> > > Hi,<br>
> > > I just scanned through the draft. I noticed that there is
no full<br>
> > > mapping of the SDP parameters from RFC3267 to generic
<br>
> parameters. Is<br>
> > > there a reason for the difference.<br>
> > > I think that there should be some text that will explain
the<br>
> > > relationship to H.245 annex I.<br>
> > > Roni Even<br>
> > ><br>
> > > -----Original Message-----<br>
> > > From: Venkata Nanduri
[<a href="mailto:vnanduri@cisco.com" eudora="autourl">mailto:vnanduri@cisco.com</a>]<br>
> > > Sent: Tuesday, January 25, 2005 12:33 AM<br>
> > > To: itu-sg16@external.cisco.com;
ari.lakaniemi@NOKIA.COM<br>
> > > Cc: vnanduri@cisco.com<br>
> > > Subject: Proposal to support AMR codec in H.245 using
RFC3267<br>
> > ><br>
> > > Dear SG16 experts,<br>
> > ><br>
> > > I would like the attached proposal to be submitted to
<br>
> next meeting of<br>
> > > SG16<br>
> > > group to be held at<br>
> > > Melbourne in February last week, 2005.<br>
> > ><br>
> > > Before I submit the proposal formally, I would like to
<br>
> get some early<br>
> > > feedback on the proposal<br>
> > > from experts in the group.<br>
> > ><br>
> > > Can you please review the document and let me know your
comments?<br>
> > ><br>
> > > Thanks<br>
> > > Venkata<br>
> > ><br>
> </blockquote></html>