Proposal to support AMR codec in H.245 using RFC3267

[Venkata Nanduri]

Hi,

Thanks for the information.

please see in line....

At 09:32 AM 1/27/2005 +0200, ari.lakaniemi at nokia.com wrote:
>hello,
>
>Although the background of the issues I mentioned about the "mode-set"
and 
>"mode-change-period" parameters is the limitations of the GSM signaling, 
>this is not explicitly mentioned in RFC 3267. This will be at least 
>somewhat clarified in the updated version. However, the point I was
trying 
>to make is that a user that is not a gateway to GSM system should be 
>discouraged to set up a session with limitations in mode changes to avoid

>interoperability problems. Maybe this could somehow addressed in your
draft?

<vnanduri>

I think it will be good if the limitations about GSM signaling are 
mentioned in your updated draft rather than the
proposal that I will be submitting which is based on RFC 3267 so that 
readers of RFC 3267 get that info
from your updated draft.

Any idea on when this latest draft mentioned below will replace RFC3267?

Do you think the proposal to H.245 should be based on this latest draft
now?

Venkata


>The problem about the "mode-change-period"'s actual meaning (i.e. is it a

>sender capability or a receiver limitation) was identified only after the

>RFC 3267 was published in this is not mentioned in the spec.
>
>We have tried to clarify these issues in the new draft revision of the 
>update to RFC 3267 publishded on Jan. 26 (see 
>http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-amr-bis-01.txt). 
>Note that there are major changes only in section 8, see especially a new

>parameter "mode-change-capability" and slightly changed definitions for 
>parameters "mode-change-period" and "mode-change-neighbor".
>
>br,
>Ari
>
>-----Original Message-----
>From: ext Venkata Nanduri [mailto:vnanduri at cisco.com]
>Sent: 27 January, 2005 08:13
>To: Lakaniemi Ari (Nokia-NRC/Helsinki)
>Cc: roni.even at polycom.co.il; itu-sg16 at external.cisco.com; Hagqvist Jari 
>(Nokia-NRC/Tampere); vdukki at cisco.com
>Subject: RE: Proposal to support AMR codec in H.245 using RFC3267
>
>
>Hi,
>
>Please see on line....
>
>At 09:58 AM 1/26/2005 +0200, ari.lakaniemi at 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 at cisco.com]
> > Sent: 26 January, 2005 00:16
> > To: Lakaniemi Ari (Nokia-NRC/Helsinki)
> > Cc: roni.even at polycom.co.il; itu-sg16 at 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 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: 20342 bytes
Desc: not available
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20050127/b9f6203a/attachment-0004.bin>