Subject: Re: [MMUSIC] [AVT] G.726 payload bitorder (RFC 3551) in current implementations

From: "Schwarz Albrecht" <[email-masked]>
Date: Wed, 9 Jun 2010 15:18:49 +0200

Carsten,

seems to be primarily an SDP Offer/Answer issue (thus, [email-masked] should be involved).
You don't show the SDP answer, just the SDP offer.

The SDP Offerer provides an Offer with two G.726 encoding schemes ("2 G.726 configurations"), which is OK. 
The Offerer expects that the Answerer is selecting 1-out-of-2 G.726 encodings ("because it doesn't make any sense to use finally two G.726 encodings in parallel").

Thus, may you guarantee that the Answerer is compliant to RFC 3264?
Could you provide the details of the SDP Answer?

You combinations indicated by your matrix are subject of the SDP O/A process.

/Albrecht

> -----Original Message-----
> From: Carsten Gross [mailto:[email-masked]] 
> Sent: Mittwoch, 9. Juni 2010 13:54
> To: Schwarz Albrecht
> Cc: Roni Even; [email-masked]
> Subject: Re: [AVT] G.726 payload bitorder (RFC 3551) in 
> current implementations
> 
> Albrecht,
> Roni,
> 
> thanks for your answers.
> 
> Am Mittwoch, 9. Juni 2010, um 08:32:40 schrieb Schwarz Albrecht:
> > Guess it's related to the last paragraph of § 4.5.4/RFC 3551:
> > 
> > [...] A second set of RTP payload formats
> >    matching the packetization of I.366.2 Annex E and 
> identified by MIME
> >    subtypes AAL2-G726-16, -24, -32 and -40 will be specified in a
> >    *separate document*.
> > 
> > 
> > The considered MIME subtypes are indicated, but such a *separate 
> > document* (for "G.726/I.366.2"-over-RTP) was never 
> produced. [and RFC 
> > 3108 is just covering the ATM-based G.726 transport (for 
> > "G.726/I.366.2"-over-AAL2/ATM)]
> 
> this is the main reason for bringing this topic onto this list. 
> 
> It seems that a lot of existing implementations are just 
> "doing the bit order wrong" (according to RFC 3551) when 
> offering plain G.726.
> 
> There is at least one implementation that tries to workaround 
> this by just announcing something like the following in the SDP: 
> 
> v=0
> o=hiQ9200 1678520100307091258 1266417729 IN IP4 
> 193.189.236.156 s=Phone Call via hiQ9200 SIPCA c=IN IP4 
> 193.189.236.156 t=0 0 m=audio 12050 RTP/AVP 8 0 18 96 97 13 100 98 99
> a=rtpmap:8 PCMA/8000
> a=fmtp:8 vad=no
> a=rtpmap:0 PCMU/8000
> a=fmtp:0 vad=no
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=yes
> a=rtpmap:96 G726-32/8000
> a=rtpmap:97 AAL2-G726-32/8000
> a=rtpmap:13 CN/8000
> a=rtpmap:100 telephone-event/8000
> a=fmtp:100 0-15
> a=rtpmap:98 PCMA/8000
> a=rtpmap:99 PCMU/8000
> a=gpmd:98 vbd=yes
> a=gpmd:99 vbd=yes
> a=sqn: 0
> a=cdsc: 1 image udptl t38
> a=sendrecv
> a=pmft: T38
> a=ptime:20
> 
> we have the situation that AAL2-G726-32 and G726-32 is offered here. 
> AAL2-G726-32 obviously means the I.366.2 bitorder but the 
> other side only understands "G726-32", ignores (the 
> would-working) "AAL2-G726-32"
> (because it's not known) and this results in broken audio. 
> 
> Trying to make a SIP-client intelligent in our network in a 
> way like this:
> 
> only G726-32 offered? -> Do the same as is done at the moment 
> 
> AAl2-G726-32 and G726-32 offered? -> Ah, now it's well 
> defined and the client knows what to do. 
> 
> is risky because AAL2-G726-32 is not defined as a possible 
> mime type in http://www.iana.org/assignments/rtp-parameters. 
> I can understand that hardware implementors prefer 
> implementing only standardised types 
> 
> Would it make sense to just finalize AAL2-G726-xx as a 
> standard mime-type in the corrosponding IANA registry for 
> SDP? This way the implementors would implement this over time 
> and AAL2-G726-xx could be preferred over plain G726-xx. 
> 
> This way a migration path could be opended: Currently I see 
> the problem that there is a big installed base obviously 
> doing the bitorder wrong and changing all components at once 
> is impossible. Therefore a migration path over a freshly 
> well-defined type (that is already mentioned and even 
> implemented by at least one hardware vendor) would open a 
> time frame to "make it right" (in the looong run).
> 
> Let's just make an example for G726-32:
> 
> G726-32 would means G726-32 as it was up-to-know. 
> Implementations doing the bit order currently "wrong" in the 
> sense of RFC 3551 should be left as they are and not "fixed". 
> If an "old" component meets a new one everything works as 
> before, as nothing in the behaviour is changed (see matrix below). 
> 
> AAL2-G726-32 should be as it is mentioned in section 4.5.4 of 
> the RFC 3551 and preferred over G726-32 (if it is known). 
> 
> Let me just draw a small matrix:
> 
> Case No   | Alice     |    Bob  | Result
> -----------------------------------------
>       1   |      G726 |    G726 |  G726
> -----------------------------------------
>       2   | AAL2-G726 |    G726 |  G726 (because Bob doesn't 
> know AAL2-G726)
>           |      G726 |         |
> -----------------------------------------
>       3   |      G726 |AAL2-G726|  G726 (because Alice 
> doesn't know AAL2-G726)
>           |           |     G726|         
> -----------------------------------------
>       4   | AAL2-G726 |AAL2-G726| AAL2-G726 (both understand it, 
>           |      G726 |     G726|   AAL2 is preferred)
> -----------------------------------------
> 
> Case 1 is as it is now, cases 2, 3 and 4 would happen during 
> a longer migration/transition phase and case 4 is the only 
> case left when all components understand both types. 
> 
> cases 2 and 3 are the reason why the current implementation 
> should not be changed, otherwise theses cases would lead to 
> broken audio. 
> 
> Could this be the correct track?
> 
> > > -----Original Message-----
> > > From: Roni Even [mailto:[email-masked]]
> > > Sent: Mittwoch, 9. Juni 2010 08:12
> > > To: Schwarz Albrecht; 'Carsten Gross'; [email-masked]
> > > Subject: RE: [AVT] G.726 payload bitorder (RFC 3551) in current 
> > > implementations
> > > 
> > > Hi,
> > > The bit order is specified in RFC 3551. I did not see any
> > > AAL2-G726 media subtype defined in the IANA registry so I am not 
> > > sure what is the expected behavior in offer answer. What Albrecht 
> > > suggested may work but I did not see this specified in the IETF 
> > > drafts.
> > > Roni Even
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] [mailto:[email-masked]] On
> > > 
> > > Behalf Of
> > > 
> > > > Schwarz Albrecht
> > > > Sent: Tuesday, June 08, 2010 3:22 PM
> > > > To: Carsten Gross; [email-masked]
> > > > Subject: Re: [AVT] G.726 payload bitorder (RFC 3551) in current 
> > > > implementations
> > > > 
> > > > Carsten,
> > > > 
> > > > your evaluation is essentially correct, that's an FAQ in
> > > 
> > > various email
> > > 
> > > > exploders (aka "secondary G.726").
> > > > 
> > > > My understanding:
> > > > the discrimination between the "little & big endian G726"
> > > 
> > > format must
> > > 
> > > > be indicated via SDP (G726 for IP, AAL2-G726 for AAL2).
> > > > Thus, the SIP/SDP profile applied in your operated SIP
> > > 
> > > domain should
> > > 
> > > > specify the usage of the particular SDP elements, and
> > > 
> > > oblige all SIP
> > > 
> > > > devices to explicitly indicate and negotiate (via SDP O/A)
> > > 
> > > the G.726
> > > 
> > > > encoding scheme.
> > > > That's the only chance in case of a SIP domain with support of 
> > > > multiple
> > > > G.726 configurations IMHO.
> > > > 
> > > > -Albrecht
> > > > 
> > > > > -----Original Message-----
> > > > > From: [email-masked] [mailto:[email-masked]]
> > > 
> > > On Behalf
> > > 
> > > > > Of Carsten Gross
> > > > > Sent: Dienstag, 8. Juni 2010 12:38
> > > > > To: [email-masked]
> > > > > Subject: [AVT] G.726 payload bitorder (RFC 3551) in current 
> > > > > implementations
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > I'm working in the VoIP developent team for an ISP in
> > > 
> > > Germany with a
> > > 
> > > > > quite big VoIP infrastructure including PSTN
> > > 
> > > interconnection using
> > > 
> > > > > voice carrier partners. We are running into an 
> interoperability 
> > > > > issue with G726-xx concerning the bit order of the 
> data in RTP 
> > > > > packets as described in RFC 3551 (section 4.5.4). We 
> use G.726 
> > > > > mainly if the bandwidth is not sufficient for a SIP 
> call using 
> > > > > G.711a/µ.
> > > > > 
> > > > > Actually I can see different implementations of G726-xx
> > > 
> > > bitorder in
> > > 
> > > > > several SIP devices. On the one hand there are PSTN media
> > > 
> > > gateways
> > > 
> > > > > e.g. from Cisco or Huawei that seem to do it always "the
> > > 
> > > old way",
> > > 
> > > > > means bit order is like it is described in ITU-T 
> Recommendation
> > > > > I.366.2 Annex E for ATM
> > > > > AAL2 transport. Other hardware (like Siemens HiQ 9200)
> > > 
> > > offers both
> > > 
> > > > > bit orders with the proposed AAL2-G726-32 and G726-32
> > > 
> > > strings in the
> > > 
> > > > > SDP. The CPE (AVM Fritz!Box
> > > > > http://www.avm.de/) we use for most customers offers a
> > > 
> > > configuration
> > > 
> > > > > option that can be switched manually. If there is a 
> third voice 
> > > > > carrier involved sometimes the bitorder information is lost 
> > > > > completly and mixed up.
> > > > > The resulting call is - of course - heavily 
> distorted. This also 
> > > > > happens if "Fritz!Box meets Siemens" in our setup.
> > > > > 
> > > > > I've read an e-mail posted on this mailing list, dated from 8 
> > > > > Jan 2003, available in the IETF mail thread archive via
> > > > > http://www.ietf.org/mail- 
> archive/web/avt/current/msg01966.html.
> > > > > 
> > > > > Despite being a quite old e-mail I'd like to (re)start a 
> > > > > discussion/recommendation and perhaps you would like to
> > > 
> > > help me with
> > > 
> > > > > the following topics:
> > > > > 
> > > > > - Despite being clear in the RFC 3551, there seems to be
> > > 
> > > not even a
> > > 
> > > > >   draft standard about the use of AAL2-G726-32 and 
> G726-32 in SDP.
> > > > 
> > > > Did
> > > > 
> > > > >   I just overlook something and there are currently just only 
> > > > > very
> > > > 
> > > > few
> > > > 
> > > > >   implementations that support both and it's recommended to
> > > > >   offer both, AAL2-G726-32 AND G726-32 in e.g. a sdp
> > > 
> > > block of a sip
> > > 
> > > > > invite?
> > > > > 
> > > > > - It seems that there are a lot of implementations that have
> > > > > 
> > > > >   the bitorder "wrong", aka not like defined in RFC 3551 (see
> > > > > 
> > > > > above). Is
> > > > > 
> > > > >   there a recommendation or a plan on how to proceed
> > > 
> > > regarding the
> > > 
> > > > > current
> > > > > 
> > > > >   situation? In contrary to the RFC most implementations
> > > 
> > > seem to do
> > > 
> > > > > it in
> > > > > 
> > > > >   the "I.366.2 way".
> > > > > 
> > > > > Regards,
> > > > > 
> > > > >    Carsten Gross
> > > > > 
> > > > > --
> > > > > 1&1 Internet AG             |   Development Consumer Products
> > > > > / DSL Core
> > > > > Ernst-Frey-Straße 9
> > > > > 76135 Karlsruhe
> > > > > Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich,
> > > > > 
> > > > >           Thomas Gottschlich, Robert Hoffmann, Markus Huhn,
> > > > >           Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
> > > > > 
> > > > > Aufsichtsrats-Vorsitzender: Michael Scheeren
> > > > > Handelsregister:  Amtsgericht Montabaur, HRB 6484 
> > > > > _______________________________________________
> > > > > Audio/Video Transport Working Group [email-masked] 
> > > > > https://www.ietf.org/mailman/listinfo/avt
> > > > 
> > > > _______________________________________________
> > > > Audio/Video Transport Working Group [email-masked] 
> > > > https://www.ietf.org/mailman/listinfo/avt
> 
> 
> Regards,
> 
>    Carsten Groß
> 
> -- 
> 1&1 Internet AG             |   Development Consumer Products 
> / DSL Core
> Ernst-Frey-Straße 9
> 76135 Karlsruhe
> Vorstand: Henning Ahlert, Ralph Dommermuth, Matthias Ehrlich, 
>           Thomas Gottschlich, Robert Hoffmann, Markus Huhn, 
>           Hans-Henning Kettler, Dr. Oliver Mauss, Jan Oetjen
> Aufsichtsrats-Vorsitzender: Michael Scheeren
> Handelsregister:  Amtsgericht Montabaur, HRB 6484
>

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Thu, 10 Jun 2010 11:59:24 +0200

The SDP O/A looks OK from my perspective.
- Both SIP UA's agree to use G726-32 (RFC 3551) as single audio format.

- the ptime would be related to a provisioned default value

- SDP capabilities of OFFERER (in addition to RFC 4566):
  * V.152 SDP,
  * RFC 3407 capability declaration
  * "a=fmtp:x vad=no" = PROPRIETARY (right?)
    [if explicit VAD indication, then via RFC 3108 'silenceSupp']

- SDP capabilities of ANSWERER (in addition to RFC 4566):
  * RFC 3605 "RTCP port allocation"

Thus, looks like a G.726 implementation issue. Hm?

/Albrecht

Side question:
what about PSTN modem calls (like fax/modem, data/modem, text/modem)?
The Offerer is proposing V.152 for all three categories, and T.38 as preference if fax/modem detected.
The Answerer isn't confirming any, neither V.152 nor T.38 (because RFC 3407 is not supported?).
Wondering whether G726-32 is considered to be also as VBD codec (but then ... what about VAD?)-

> Sent: Mittwoch, 9. Juni 2010 17:34
> To: Schwarz Albrecht
> Cc: Roni Even; [email-masked]; [email-masked]
> Am Mittwoch, 9. Juni 2010, um 15:18:49 schrieb Schwarz Albrecht:
> > seems to be primarily an SDP Offer/Answer issue (thus, 
> [email-masked] 
> > should be involved). You don't show the SDP answer, just 
> the SDP offer.
> 
> Sorry for just pasting the offer, this is the SDP offer (repeat):
> 
> v=0
> o=hiQ9200 1678520100307091258 1266417729 IN IP4 193.189.236.156 
> s=Phone Call via hiQ9200 SIPCA 
> c=IN IP4 193.189.236.156 
> t=0 0 
> m=audio 12050 RTP/AVP 8 0 18 96 97 13 100 98 99
> a=rtpmap:8 PCMA/8000
> a=fmtp:8 vad=no
> a=rtpmap:0 PCMU/8000
> a=fmtp:0 vad=no
> a=rtpmap:18 G729/8000
> a=fmtp:18 annexb=yes
> a=rtpmap:96 G726-32/8000
> and this the SDP answer from the "other side" 
> (CPE, AVM FRITZ!Box 7141 40.04.76)
> 
> v=0
> o=user 14805758 14805758 IN IP4 217.88.220.51 
> s=Phone Call via hiQ9200 SIPCA 
> c=IN IP4 217.88.220.51 
> t=0 0 
> m=audio 7082 RTP/AVP 96 100
> a=rtpmap:96 G726-32/8000
> a=fmtp:100 0-11
> a=rtcp:7083
> The CPE decides for G726-32 here, because the bandwidth is 
> not sufficent for G.711a/µ but sufficent for G726-32. The CPE 
> currently doesn't know what "AAL2-G726-32" is. 
> 
> The communication following afterwards has Payload type 96 
> from both sides. 
> Sometimes that SDP offerer also sends occasional "Comfort 
> noise" packets with PT 13 (as far as I can tell it shouldn't). 
> 
> > The SDP Offerer provides an Offer with two G.726 encoding 
> schemes ("2 
> > G.726 configurations"), which is OK. The Offerer expects that the 
> > Answerer is selecting 1-out-of-2 G.726 encodings ("because 
> it doesn't 
> > make any sense to use finally two G.726 encodings in parallel").
> > 
> > You combinations indicated by your matrix are subject of 
> the SDP O/A 
> > process.
> 
> Thanks for your help.
> 
> "doing the 
> > > bit order wrong" (according to RFC 3551) when offering 
> plain G.726.
> > > 
> > > There is at least one implementation that tries to 
> workaround this 
> > > by just announcing something like the following in the SDP:
> > > 
> > > v=0
> > > 193.189.236.156 t=0 0 m=audio 12050 RTP/AVP 8 0 18 96 97 
> 13 100 98 
> > > 99
> > > a=rtpmap:8 PCMA/8000
> > > a=fmtp:8 vad=no
> > > a=rtpmap:0 PCMU/8000
> > > a=fmtp:0 vad=no
> > > a=rtpmap:18 G729/8000
> > > a=fmtp:18 annexb=yes
> > > a=rtpmap:96 G726-32/8000
> > > Trying to make a SIP-client intelligent in our network in 
> a way like 
> > > this:
> > > 
> > > is risky because AAL2-G726-32 is not defined as a 
> possible mime type 
> > > in http://www.iana.org/assignments/rtp-parameters.
> > > Would it make sense to just finalize AAL2-G726-xx as a standard 
> > > mime-type in the corrosponding IANA registry for SDP? 
> This way the 
> > > implementors would implement this over time and 
> AAL2-G726-xx could 
> > > be preferred over plain G726-xx.
> > > 
> > > This way a migration path could be opended: Currently I see the 
> > > problem that there is a big installed base obviously doing the 
> > > bitorder wrong and changing all components at once is impossible. 
> > > Therefore a migration path over a freshly well-defined 
> type (that is 
> > > already mentioned and even implemented by at least one hardware 
> > > vendor) would open a time frame to "make it right" (in the looong 
> > > run).
> > > 
> > > Implementations doing the bit order currently "wrong" in 
> the sense 
> > > of RFC 3551 should be left as they are and not "fixed".
> before, as 
> > > nothing in the behaviour is changed (see matrix below).
> > > 
> > > AAL2-G726-32 should be as it is mentioned in section 4.5.4 of the 
> > > RFC 3551 and preferred over G726-32 (if it is known).
> > > 
> > > Case 1 is as it is now, cases 2, 3 and 4 would happen during a 
> > > longer migration/transition phase and case 4 is the only 
> case left 
> > > when all components understand both types.
> > > 
> > > cases 2 and 3 are the reason why the current 
> implementation should 
> > > not be changed, otherwise theses cases would lead to broken audio.
> > > 
> > > [..shorted due to broken formatting..]
> 
> Best regards,
> 
>    Carsten Gross
> 
> --

---

From: "Roni Even" <[email-masked]>
Date: Mon, 14 Jun 2010 17:05:16 +0300

Hi,
Since the implementation is not according to the standard, SDP signaling
will not help here.
The only thing that may help is deep packet inspection trying to understand
from the payload what is the bit order and transcode or try to use another
codec
Roni

> Sent: Monday, June 14, 2010 12:19 PM
> To: Schwarz Albrecht
> Am Donnerstag, 10. Juni 2010, um 11:59:24 schrieb Schwarz Albrecht:
> unfortunatly it *seems* that they agree, but ...
> 
> ... they both agree on G726-32 but the answerer (here: the Fritz!Box)
> uses G.726-32 in AAL2 format and the SDP offerer in RFC 3551 format.
> Therefore the resulting audio is broken in both directorions.
> This is due to the fact that the "rest of the network" is implemented
> in the "wrong" bitorder according to RFC 3551, including other
> commercial MGW implementations (Cisco, Huawei).
> 
> Unfortunatly I cannot tell in deep-details of the SDP offerer.
> 
> > The Offerer is proposing V.152 for all three categories, and T.38 as
> > preference if fax/modem detected. The Answerer isn't confirming any,
> > neither V.152 nor T.38 (because RFC 3407 is not supported?).
> Wondering
> > whether G726-32 is considered to be also as VBD codec (but then ...
> what
> > about VAD?)-
> 
> In the case of a fax transmission (fax tones are detected in the
> transmission)
> the answerer (the Fritz!Box) does a re-INVITE for T.38 via SIP. Similar
> happens if the bandwidth gets sufficient for a PCMA/G.711a
> transmission.
> Actually this are mainly observations done by myself, not in deep
> knowledge of
> the implementation of the CPE. I'd just like to understand how it is
> possible
> to proceed with the problem that G.726 just seems to be implemented in
> the
> "wrong" bitorder (according to RFC 3551) in most devices and how to do
> it
> right in the future.
> 
> Regards,
> 
>    Carsten Gross
> 
> --
> 1&1 Internet AG             |   Development Consumer Products / DSL
> Core
> Ernst-Frey-Straße 9
> 76135 Karlsruhe