Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt

[David R Oran <[e-mail]>]

On Mar 8, 2012, at 8:13 AM, Chhatwal, Harprit S wrote:

> I didn’t fully understand your network. My guess is that  in case of bandwidth constrained in one direction of the session, then the low-bandwidth codec has to be negotiated in that direction. ISTM, asymmetric annexb parameter negotiation is not going to solve the bandwidth issue. Please let me know how asymmetric annexb will solve bandwidth issue. 
> 
> 
> Perhaps I have not explained this clearly enough previously, so allow me to try again.  The bandwidth in the customer's network is sufficiently constrained in one direction that the customer wishes to use G.729/G.729A with G.729B active (ie using VAD/DTX) to allow the speech codec bandwidth requirements in this direction to fit within the network bandwidth envelope. In the other direction, the network bandwidth available is somewhat less constrained, so the customer would like to use G.729/G.729A without G.729B active to get slightly better quality.  
Well, even if you've negotiated it, it doesn't mean you actually have to use it. If the endpoint is smart enough to know whether to negotiate it or not, I suspect it's smart enough to know not to bother using it when the bandwidth is sufficient.

Seems like a corner case, although the general problem of how to do asymmetric codec negotiation probably has more compelling use cases.

> However, even in this direction, the network bandwidth is still limited enough that a higher-rate codec such as G.711 will not work.
> 
> For the second part of your question, please see the earlier mails on this thread as this has been covered previously.
> 
> Regards.  Harprit.
> 
> Harprit S. Chhatwal
> InnoMedia
> 
> On 8 March 2012 10:12, Ravindran, Parthasarathi <[e-mail]> wrote:
> Hi Harpit,
> 
>  
> 
> Sorry for the delay reply.
> 
>  
> 
> I didn’t fully understand your network. My guess is that  in case of bandwidth constrained in one direction of the session, then the low-bandwidth codec has to be negotiated in that direction. ISTM, asymmetric annexb parameter negotiation is not going to solve the bandwidth issue. Please let me know how asymmetric annexb will solve bandwidth issue.
> 
>  
> 
> AFAIK, answerer expectation of asymmetric annexb will leads to the interop issue in case of offerer mentions as “annexb=no” but answerer mandates to have “annexb=yes”.  Please let me know your opinion on the same.
> 
> 
> Thanks
> Partha
> 
>  
> 
>  
> 
>  
> 
> From: Chhatwal, Harprit S [mailto:[e-mail]] 
> Sent: Thursday, March 01, 2012 4:59 PM
> To: Ravindran, Parthasarathi
> Cc: Paul Kyzivat; Kevin P. Fleming; [e-mail]
> 
> 
> Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-g723-g729-00.txt
> 
>  
> 
> On 1 March 2012 06:13, Ravindran, Parthasarathi <[e-mail]> wrote:
> 
> I'm not very clear on the bandwidth optimization based on asymmetric annexb parameter negotiation. Could you please elaborate.
> 
>  
> 
> This is for a network where the bandwidth is severely constrained in one direction, so the operator wishes to use G.729B to minimise bandwidth usage in one direction, while not using G.729B in the other direction where bandwidth is less constrained.
> 
>  
> 
> Regards.  Harprit.
> 
>  
> 
> Harprit S. Chhatwal
> 
> InnoMedia
> 
>  
> 
> On 1 March 2012 06:13, Ravindran, Parthasarathi <[e-mail]> wrote:
> 
> Hi Harpit,
> 
> Thanks for looking into the draft. I agree with you that asymmetric annexb negotiation is not taken into the account in the draft currently. In fact, I come across the scenario wherein annexb is not supported by offerer ,mentioned in offer SDP as annexb=no and answerer assumes about annexb support (no annexb parameter in answer) in offerer side which leads to the call failure.
> 
> I'm not very clear on the bandwidth optimization based on asymmetric annexb parameter negotiation. Could you please elaborate.
> 
> Thanks
> Partha
> 
> 
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On
> >Behalf Of Paul Kyzivat
> >Sent: Wednesday, February 29, 2012 9:01 PM
> >To: Chhatwal, Harprit S
> >Cc: [e-mail]
> >Subject: Re: [payload] FW: I-D Action: draft-muthu-payload-offer-answer-
> >g723-g729-00.txt
> >
> >On 2/29/12 9:34 AM, Chhatwal, Harprit S wrote:
> >> On 28 February 2012 21:01, Kevin P. Fleming <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>
> >>     That requirement is counter to what the draft proposes. We can't
> >>     have it both ways: either the G.729 'annexb' format parameter is a
> >>     negotiated parameter (in which case its usage is symmetrical by
> >>     definition) or it is a declarative parameter (in which case the
> >>     usage can be, but is not required to be, asymmetrical).
> >>
> >>
> >> Yes, I concur that the draft (as it currently stands) cannot
> >> accommodate an asymmetric use of G.729B.  However, if we agree that
> >> both scenarios are true, real-world scenarios that need addressing, ie
> >> (a) the negotiated case where the use of G.729B is symmetric and (b)
> >> the declarative case where the use of G.729B can be asymmetric (and,
> >> in my opinion, both are valid scenarios), then I would suggest that we
> >> need to come up with a way of handling both situations (perhaps
> >> through the use of an extra fmtp parameter indicating whether the use
> >> is declarative or negotiated - or any other suggestions the group
> >might have).
> >>
> >> If not, and we are only to allow the negotiated, symmetric use, then
> >> I'd appreciate any suggestions from the group for how my organisation
> >> might deal with the requirement of an asymmetric use of G.729B
> >mentioned below.
> >
> >There is one way that is available right now:
> >
> >Negotiate two separate one way m-lines.
> >But this might be too weird for common use.
> >
> >       Thanks,
> >       Paul
> >
> >> Regards.  Harprit.
> >>
> >> Harprit S. Chhatwal
> >> InnoMedia
> >>
> >> On 28 February 2012 21:01, Kevin P. Fleming <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>     On 02/28/2012 02:58 PM, Chhatwal, Harprit S wrote:
> >>
> >>         Speaking as a codec person :-), I think the draft does address
> >a
> >>         real
> >>         issue and is reasonably clear in its content.  However, it
> >does not
> >>         appear to address (as far as I can see), the case where an
> >>         asymmetric
> >>         use of G.729B is required.  This is an actual issue as we are
> >>         faced with
> >>         a customer requirement where the use of G.729B is required in
> >one
> >>         direction and not the other (for bandwidth reasons).  Given
> >the
> >>         current
> >>         specs do not appear to definitively cover this case, it would
> >be
> >>         good to
> >>         see if this can be addressed through the proposed draft.
> >>
> >>
> >>     That requirement is counter to what the draft proposes. We can't
> >>     have it both ways: either the G.729 'annexb' format parameter is a
> >>     negotiated parameter (in which case its usage is symmetrical by
> >>     definition) or it is a declarative parameter (in which case the
> >>     usage can be, but is not required to be, asymmetrical).
> >>
> >>
> >>         Regards.  Harprit.
> >>
> >>         Harprit S. Chhatwal
> >>         InnoMedia
> >>
> >>         On 28 February 2012 19:10, Kevin P. Fleming
> >>         <[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>>
> >wrote:
> >>
> >>             On 02/28/2012 12:07 PM, Paul Kyzivat wrote:
> >>
> >>                 Clarification:
> >>
> >>                 In my comments on the draft I was not questioning the
> >>         assumption
> >>                 of that
> >>                 draft that a common value of this parameter is
> >>         *negotiated* via O/A.
> >>                 *If* you accept that assumption then my comments
> >>         hopefully make
> >>                 sense.
> >>
> >>                 But if there is debate regarding whether the parameter
> >is
> >>                 negotiated or
> >>                 declarative, then that needs to be settled first,
> >before
> >>         nailing
> >>                 down
> >>                 clarifications for how the negotiation happens.
> >>
> >>                 Not being a codec person, I don't know what the common
> >>         practice
> >>                 is here.
> >>                 So I'm going to let those that have the knowledge
> >argue
> >>         that.
> >>
> >>
> >>             Correct on all points; your comments make complete sense
> >if
> >>         'annexb'
> >>             is intended to be a negotiated parameter.
> >>
> >>             I'm not a codec person (although I'd probably be willing
> >to
> >>         play one
> >>             on TV is the need arose <G>), but there are so many other
> >>             codec/format parameters that are declarative already that
> >I
> >>         don't
> >>             see any need for this one to have to be negotiated. The
> >>         impact of
> >>             using Annex B or not is purely on one direction of the
> >media
> >>         stream,
> >>             and it's not even mandatory that the encoder use Annex B
> >>         mode just
> >>             because 'annexb=yes'. Granted, it's pretty unlikely that
> >an
> >>             implementation that cannot accept incoming SID frames
> >would
> >>         also be
> >>             able to generate them, but I can think of completely
> >reasonable
> >>             situations for an implementation that can generate them
> >being
> >>             willing to do so while at the same time disallowing
> >>         reception of them.
> >>
> >>
> >>
> >>                 Thanks,
> >>                 Paul
> >>
> >>                 On 2/28/12 12:34 PM, Chhatwal, Harprit S wrote:
> >>
> >>                     Kevin,
> >>
> >>                     First of all, from RFC3264, I agree with you that
> >>         for things
> >>                     like IP
> >>                     addresses, ports, payload types, ptime, the SDP
> >that one
> >>                     party sends
> >>                     indicates the address/port/PT/ptime that the
> >sender
> >>         would
> >>                     like to
> >>                     receive on. However, I don't believe this is
> >generally
> >>                     correct for all
> >>                     parameters. For instance, for codecs (again from
> >>         RFC3264),
> >>                     the codec(s)
> >>                     included in an SDP offer indicates the codec(s)
> >the
> >>         offerer
> >>                     is willing
> >>                     to send AND receive (if the directional attribute
> >is
> >>                     'sendrecv'). As an
> >>                     example, if party A is the offerer and sends G.729
> >&
> >>         G.711
> >>                     in its SDP
> >>                     offer, it is saying that it is willing to use
> >either
> >>         codec.
> >>                     If the
> >>                     answerer replies with G.711, then it is only
> >willing
> >>         to use
> >>                     G.711, and
> >>                     then G.729 will not be used in either direction.
> >>
> >>                     Turning now to silence suppression, the situation
> >>         does not
> >>                     seem very
> >>                     clear. This is what RFC3264 has to say about fmtp
> >>         parameters
> >>                     such as
> >>                     'annexb' :
> >>
> >>                     The interpretation of fmtp parameters in an offer
> >>         depends on the
> >>
> >>                     parameters. In many cases, those parameters
> >describe
> >>         specific
> >>
> >>                     configurations of the media format, and should
> >>         therefore be
> >>                     processed
> >>
> >>                     as the media format value itself would be. This
> >>         means that
> >>                     the same
> >>
> >>                     fmtp parameters with the same values MUST be
> >present
> >>         in the
> >>                     answer if
> >>
> >>                     the media format they describe is present in the
> >answer.
> >>                     Other fmtp
> >>
> >>                     parameters are more like parameters, for which it
> >is
> >>         perfectly
> >>
> >>                     acceptable for each agent to use different values.
> >>         In that
> >>                     case, the
> >>
> >>                     answer MAY contain fmtp parameters, and those MAY
> >>         have the same
> >>
> >>                     values as those in the offer, or they MAY be
> >>         different. SDP
> >>
> >>                     extensions that define new parameters SHOULD
> >specify
> >>         the proper
> >>
> >>                     interpretation in offer/answer.
> >>
> >>                     To me, 'annexb' is more like a parameter in this
> >>         sense and,
> >>                     in this
> >>                     case, everything is allowed - the answer may
> >contain the
> >>                     same fmtp or
> >>                     different. RFC3264 doesn't appear to specify the
> >>                     interpretation. The
> >>                     problem is that I don't know of anywhere else
> >where the
> >>                     interpretation
> >>                     is specified either. RFC4856 specifies the
> >parameter
> >>                     'annexb', but
> >>                     doesn't say whether it can be used asymmetrically
> >>         (or how).
> >>                     The only
> >>                     other guidance I can find on this is elsewhere in
> >>         RFC3264:
> >>
> >>                     The list of media formats for each media stream
> >>         conveys two
> >>                     pieces of
> >>
> >>                     information, namely the set of formats (codecs and
> >any
> >>                     parameters
> >>
> >>                     associated with the codec, in the case of RTP)
> >that the
> >>                     offerer is
> >>
> >>                     capable of sending and/or receiving (depending on
> >>         the direction
> >>
> >>                     attributes)...
> >>
> >>                     ...For a sendrecv stream, the offer SHOULD
> >indicate
> >>         those
> >>
> >>                     codecs that the offerer is willing to send and
> >>         receive with.
> >>
> >>                     So, this appears to be lumping codec parameters
> >with
> >>         codecs
> >>                     and so both
> >>                     should behave in the same way. If we take this
> >>                     interpretation, then
> >>                     indicating 'annexb=no' indicates that the sender
> >of
> >>         this SDP
> >>                     is willing
> >>                     to send and receive with silence suppression off.
> >So,
> >>                     according to
> >>                     this, if the offerer sends 'annexb=yes' in the
> >offer
> >>         and the
> >>                     answerer
> >>                     sends back 'annexb=no', then there is a mismatch
> >and the
> >>                     offerer should
> >>                     send a re-INVITE with 'annexb=no' to resolve the
> >>         conflict.
> >>                     According to
> >>                     this interpretation, we cannot have an asymmetric
> >>         use of silence
> >>                     suppression. However, from the discussion we're
> >>         having, I
> >>                     can see that
> >>                     all of this is somewhat open to interpretation
> >>         (since the
> >>                     specs do not
> >>                     seem to be clear) and I agree with the authors of
> >>         this ID
> >>                     that we need
> >>                     some clarification as to how this issue should be
> >>         dealt with
> >>                     (and
> >>                     whether asymmetric use of annexb should be allowed
> >>         and, if
> >>                     so, how).
> >>
> >>
> >>                     Regards. Harprit.
> >>
> >>
> >>                     Harprit S. Chhatwal
> >>
> >>                     InnoMedia
> >>
> >>
> >>                     On 28 February 2012 16:54, Kevin P. Fleming
> >>         <[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>
> >>         <mailto:[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail]
> >> <mailto:[e-mail]>>>__>
> >>
> >>                     wrote:
> >>
> >>                     On 02/27/2012 11:12 AM, Paul Kyzivat wrote:
> >>
> >>                     On 2/27/12 6:33 AM, Muthu Arul Mozhi Perumal
> >>         (mperumal) wrote:
> >>
> >>                     We have submitted an I-D clarifying the
> >offer/answer
> >>                     considerations for
> >>                     the Annex A flavor of G.723 and the Annex B
> >flavors of
> >>                     G.729, G.729D and
> >>                     G.729E. This clarification is missing in RFC 4856,
> >>         leading
> >>                     to interop
> >>                     issues, for e.g:
> >>         http://sipforum.org/pipermail/______discussion/2008-
> >January/______004026.html
> >>         <http://sipforum.org/pipermail/____discussion/2008-
> >January/____004026.html>
> >>         <http://sipforum.org/__pipermail/__discussion/2008-
> >__January/__004026.html
> >>         <http://sipforum.org/pipermail/__discussion/2008-
> >January/__004026.html>>
> >>         <http://sipforum.org/____pipermail/discussion/2008-
> >____January/004026.html
> >>
> >> <http://sipforum.org/__pipermail/discussion/2008-__January/004026.html
> >> >
> >>
> >>         <http://sipforum.org/__pipermail/discussion/2008-
> >__January/004026.html
> >>
> >> <http://sipforum.org/pipermail/discussion/2008-January/004026.html>>>
> >>
> >>                     We have a couple of open items in the I-D. We
> >expect
> >>         the WG
> >>                     discussions
> >>                     would guide us on how to go about them.
> >>
> >>                     Comments welcome.
> >>
> >>
> >>                     I'm the source of the issues. :-)
> >>
> >>                     The fundamental point is that RFC4856 specifies a
> >>         *default*
> >>                     value of
> >>         "yes" for annexa and annexb. This means that if
> >>                     annexa/annexb is not
> >>                     specified in an answer, then it will default to
> >yes,
> >>         even if the
> >>                     offer
> >>                     contained "no".
> >>
> >>                     I see a few ways to fix this:
> >>
> >>                     1) revise the IANA registration for annexa and
> >annexb to
> >>                     remove the
> >>                     default, at least when used with O/A. Instead
> >>         specify the
> >>                     defaulting
> >>                     separately for offers and answers.
> >>
> >>                     2) REQUIRE that the answer contain "no" if the
> >offer
> >>                     contained "no".
> >>
> >>                     3) permit the answer to contain "yes" (explicitly
> >or
> >>         by default)
> >>                     when the offer contained "no", and specify that
> >this
> >>         still means
> >>                     that the annex is *not* to be used.
> >>
> >>                     4) forbid the answer from *explicitly* containing
> >>         "yes" when the
> >>                     offer contained "no", but allow the answer to
> >>         *implicitly*
> >>                     contain
> >>         "yes" (via the default) and ignore it/treat it as "no".
> >>
> >>                     None of these are ideal. (1) is problematic
> >because
> >>         this is
> >>                     used in
> >>                     non-O/A contexts, such as RSVP. (2) begs the
> >>         question of what
> >>                     should be
> >>                     done if this is violated. (3) risks failing to
> >>         recognize that
> >>                     the two
> >>                     sides disagree. (4) is pragmatic but seems to
> >>         violate the
> >>                     spirit of
> >>                     defaults.
> >>
> >>                     I guess my preference is to make (2) normative for
> >>         the answerer,
> >>                     while
> >>                     making (4) normative for the offerer, and put
> >enough
> >>         words
> >>                     in so its
> >>                     very clear what is being specified and why.
> >>
> >>
> >>                     I must *really* be missing something here; why
> >does
> >>         the usage of
> >>                     G.729 Annex B have to be symmetrical? Until I saw
> >this
> >>                     thread, it
> >>                     was always my understanding that the 'annexb'
> >format
> >>                     parameter for
> >>                     G.729 in SDP indicated the preference of the
> >endpoint
> >>                     sending that
> >>                     parameter. Like nearly everything else in SDP, it
> >>         indicates what
> >>                     that endpoint is *prepared to accept*, and has
> >>         nothing at
> >>                     all to do
> >>                     with what it will (or could) send.
> >>
> >>                     Unless that's a completely broken understanding,
> >>         then these
> >>         'interop' issues are really just very poorly coded
> >>                     implementations.
> >>                     I would interpret the current RFC language as
> >follows:
> >>
> >>                     1) If an offer/answer contains 'annexb=no', the
> >>         receiver of that
> >>                     offer/answer MUST NOT send G.729 Annex B SID
> >frames
> >>         to the
> >>                     offering/answering endpoint.
> >>
> >>                     2) If an offer/answer contains 'annexb=yes', the
> >>         receiver of
> >>                     that
> >>                     offer/answer SHOULD send G.729 Annex B SID frames
> >to the
> >>                     offering/answering endpoint.
> >>
> >>                     3) An answer's value for the 'annexb' parameter is
> >>         completely
> >>                     independent of the value (if any) present in the
> >>         offer it is
> >>                     answering.
> >>
> >>
> >>                     Thanks,
> >>                     Paul
> >>
> >>                     Muthu
> >>
> >>                     -----Original Message-----
> >>                     From: [e-mail]
> >>         <mailto:[e-mail]>
> >>         <mailto:i-d-announce-bounces@__ietf.org
> >>         <mailto:[e-mail]>>
> >>         <mailto:i-d-announce-bounces@
> >>         <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
> >>         <mailto:i-d-announce-bounces@__ietf.org
> >>         <mailto:[e-mail]>>>
> >>                     [mailto:i-d-announce-bounces@
> >>         <mailto:i-d-announce-bounces@>
> >>         <mailto:i-d-announce-bounces@
> >>         <mailto:i-d-announce-bounces@>>______ietf.org
> ><http://ietf.org>
> >>         <http://ietf.org>
> >>         <mailto:i-d-announce-bounces@
> >>         <mailto:i-d-announce-bounces@>____ietf.org <http://ietf.org>
> >>         <mailto:i-d-announce-bounces@__ietf.org
> >>         <mailto:[e-mail]>>>] On Behalf Of
> >>         [e-mail] <mailto:[e-mail]>
> >>         <mailto:internet-drafts@ietf.__org
> >>         <mailto:[e-mail]>>
> >>         <mailto:internet-drafts@ietf.
> >> <mailto:internet-drafts@ietf.>____org
> >>
> >>         <mailto:internet-drafts@ietf.__org
> >>         <mailto:[e-mail]>>>
> >>                     Sent: Friday, February 24, 2012 5:57 PM
> >>                     To: [e-mail]
> >>         <mailto:[e-mail]> <mailto:[e-mail]
> >>         <mailto:[e-mail]>>
> >>         <mailto:[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:i-d-
> >[e-mail]>>__>
> >>                     Subject: I-D Action:
> >>
> >> draft-muthu-payload-offer-______answer-g723-g729-00.txt
> >>
> >>
> >>
> >>                     A New Internet-Draft is available from the on-line
> >>                     Internet-Drafts
> >>                     directories.
> >>
> >>                     Title : Offer/Answer Considerations for G.723
> >Annex A
> >>                     and G.729 Annex B
> >>                     Author(s) : Muthu Arul Mozhi Perumal
> >>                     Parthasarathi Ravindran
> >>                     Filename :
> >>
> >> draft-muthu-payload-offer-______answer-g723-g729-00.txt
> >>
> >>                     Pages : 8
> >>                     Date : 2012-02-24
> >>
> >>                     [RFC4856] describes the annexa parameter for G723
> >>         and the annexb
> >>                     parameter for G729, G729D and G729E. However, the
> >>                     specification does
> >>                     not describe the offerer and answerer behavior
> >when the
> >>                     value of the
> >>                     annexa or annexb parameter does not match in the
> >SDP
> >>         offer and
> >>                     answer. This document provides the offer/answer
> >>                     considerations for
> >>                     these parameters.
> >>
> >>
> >>                     A URL for this Internet-Draft is:
> >>         http://www.ietf.org/internet-______drafts/draft-muthu-payload-
> >______offer-answer-g72
> >>         <http://www.ietf.org/internet-____drafts/draft-muthu-payload-
> >____offer-answer-g72>
> >>         <http://www.ietf.org/internet-____drafts/draft-muthu-payload-
> >____offer-answer-g72
> >>
> >> <http://www.ietf.org/internet-__drafts/draft-muthu-payload-__offer-ans
> >> wer-g72>>
> >>
> >>
> >>         <http://www.ietf.org/internet-____drafts/draft-muthu-payload-
> >____offer-answer-g72
> >>         <http://www.ietf.org/internet-__drafts/draft-muthu-payload-
> >__offer-answer-g72>
> >>         <http://www.ietf.org/internet-__drafts/draft-muthu-payload-
> >__offer-answer-g72
> >>
> >> <http://www.ietf.org/internet-drafts/draft-muthu-payload-offer-answer-
> >> g72>>>
> >>
> >>                     3-g729-00.txt
> >>
> >>                     Internet-Drafts are also available by anonymous
> >FTP at:
> >>         ftp://ftp.ietf.org/internet-______drafts/
> >>         <ftp://ftp.ietf.org/internet-____drafts/>
> >>         <ftp://ftp.ietf.org/internet-____drafts/
> >>         <ftp://ftp.ietf.org/internet-__drafts/>>
> >>
> >>         <ftp://ftp.ietf.org/internet-____drafts/
> >>         <ftp://ftp.ietf.org/internet-__drafts/>
> >>         <ftp://ftp.ietf.org/internet-__drafts/
> >>         <ftp://ftp.ietf.org/internet-drafts/>>>
> >>
> >>                     This Internet-Draft can be retrieved at:
> >>         ftp://ftp.ietf.org/internet-______drafts/draft-muthu-payload-
> >______offer-answer-g723
> >>         <ftp://ftp.ietf.org/internet-____drafts/draft-muthu-payload-
> >____offer-answer-g723>
> >>         <ftp://ftp.ietf.org/internet-____drafts/draft-muthu-payload-
> >____offer-answer-g723
> >>
> >> <ftp://ftp.ietf.org/internet-__drafts/draft-muthu-payload-__offer-answ
> >> er-g723>>
> >>
> >>
> >>         <ftp://ftp.ietf.org/internet-____drafts/draft-muthu-payload-
> >____offer-answer-g723
> >>         <ftp://ftp.ietf.org/internet-__drafts/draft-muthu-payload-
> >__offer-answer-g723>
> >>         <ftp://ftp.ietf.org/internet-__drafts/draft-muthu-payload-
> >__offer-answer-g723
> >>
> >> <ftp://ftp.ietf.org/internet-drafts/draft-muthu-payload-offer-answer-g
> >> 723>>>
> >>
> >>                     -g729-00.txt
> >>
> >>
> >> _____________________________________________________
> >>
> >>                     I-D-Announce mailing list
> >>         [e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>
> >>         <mailto:[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:I-D-
> >[e-mail]>>__>
> >>         https://www.ietf.org/mailman/______listinfo/i-d-announce
> >>         <https://www.ietf.org/mailman/____listinfo/i-d-announce>
> >>         <https://www.ietf.org/mailman/____listinfo/i-d-announce
> >>         <https://www.ietf.org/mailman/__listinfo/i-d-announce>>
> >>
> >>         <https://www.ietf.org/mailman/____listinfo/i-d-announce
> >>         <https://www.ietf.org/mailman/__listinfo/i-d-announce>
> >>         <https://www.ietf.org/mailman/__listinfo/i-d-announce
> >>         <https://www.ietf.org/mailman/listinfo/i-d-announce>>>
> >>                     Internet-Draft directories:
> >>         http://www.ietf.org/shadow.______html
> >>         <http://www.ietf.org/shadow.____html>
> >>         <http://www.ietf.org/shadow.____html
> >>         <http://www.ietf.org/shadow.__html>>
> >>         <http://www.ietf.org/shadow.____html
> >>         <http://www.ietf.org/shadow.__html>
> >>         <http://www.ietf.org/shadow.__html
> >>         <http://www.ietf.org/shadow.html>>>
> >>                     or ftp://ftp.ietf.org/ietf/______1shadow-sites.txt
> >>         <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt>
> >>         <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt
> >>         <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt>>
> >>         <ftp://ftp.ietf.org/ietf/____1shadow-sites.txt
> >>         <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt>
> >>         <ftp://ftp.ietf.org/ietf/__1shadow-sites.txt
> >>         <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>>>
> >>
> >>
> >>
> >> _____________________________________________________
> >>
> >>                     payload mailing list
> >>         [e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>
> >>         <mailto:[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>>
> >>         https://www.ietf.org/mailman/______listinfo/payload
> >>         <https://www.ietf.org/mailman/____listinfo/payload>
> >>         <https://www.ietf.org/mailman/____listinfo/payload
> >>         <https://www.ietf.org/mailman/__listinfo/payload>>
> >>
> >>         <https://www.ietf.org/mailman/____listinfo/payload
> >>         <https://www.ietf.org/mailman/__listinfo/payload>
> >>         <https://www.ietf.org/mailman/__listinfo/payload
> >>         <https://www.ietf.org/mailman/listinfo/payload>>>
> >>
> >>
> >>
> >>                     --
> >>                     Kevin P. Fleming
> >>                     Digium, Inc. | Director of Software Technologies
> >>                     Jabber: [e-mail]
> >>         <mailto:[e-mail]> <mailto:[e-mail]
> >>         <mailto:[e-mail]>>
> >>         <mailto:[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>> |
> >SIP:
> >>         [e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>
> >>         <mailto:[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>>
> >>
> >>                     | Skype: kpfleming
> >>                     445 Jan Davis Drive NW - Huntsville, AL 35806 -
> >USA
> >>                     Check us out at www.digium.com
> >>         <http://www.digium.com> <http://www.digium.com>
> >>         <http://www.digium.com> &
> >>         www.asterisk.org <http://www.asterisk.org>
> ><http://www.asterisk.org>
> >>         <http://www.asterisk.org>
> >>
> >> _____________________________________________________
> >>
> >>                     payload mailing list
> >>         [e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>
> >>         <mailto:[e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>>>
> >>         https://www.ietf.org/mailman/______listinfo/payload
> >>         <https://www.ietf.org/mailman/____listinfo/payload>
> >>         <https://www.ietf.org/mailman/____listinfo/payload
> >>         <https://www.ietf.org/mailman/__listinfo/payload>>
> >>
> >>         <https://www.ietf.org/mailman/____listinfo/payload
> >>         <https://www.ietf.org/mailman/__listinfo/payload>
> >>         <https://www.ietf.org/mailman/__listinfo/payload
> >>         <https://www.ietf.org/mailman/listinfo/payload>>>
> >>
> >>
> >>
> >>
> >>
> >>             --
> >>             Kevin P. Fleming
> >>             Digium, Inc. | Director of Software Technologies
> >>             Jabber: [e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>> |
> >SIP:
> >>         [e-mail] <mailto:[e-mail]>
> >>         <mailto:[e-mail] <mailto:[e-mail]>> |
> >>         Skype: kpfleming
> >>
> >>             445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> >>             Check us out at www.digium.com <http://www.digium.com>
> >>         <http://www.digium.com> &
> >>         www.asterisk.org <http://www.asterisk.org>
> >> <http://www.asterisk.org>
> >>
> >>
> >>
> >>
> >>     --
> >>     Kevin P. Fleming
> >>     Digium, Inc. | Director of Software Technologies
> >>     Jabber: [e-mail] <mailto:[e-mail]> | SIP:
> >>     [e-mail] <mailto:[e-mail]> | Skype:
> >kpfleming
> >>     445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> >>     Check us out at www.digium.com <http://www.digium.com> &
> >>     www.asterisk.org <http://www.asterisk.org>
> >>
> >>
> >
> 
> >_______________________________________________
> >payload mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/payload
> 
>  
> 
> 
> _______________________________________________
> payload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/payload