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

"Roni Even" <ron.even.tlv@gmail.com> Mon, 14 June 2010 14:07 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; b=cQPRMnnHm1oE790CTh4OPSQA1p+gnMHoRyAWBJgbpBxPEryZrM0j4rtyHnuT+S04Ol VTDEyR/JCeiSPU6NLUaalJBlPjNW/ANICV5TLPj4GrbXBIszdDCEjOcwyEzB8RTwXRAA lCJMQczLooeVMCO9UoBn/HiB2L8u5P3kTU9II=
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Carsten Gross' <carsten.gross@1und1.de>, 'Schwarz Albrecht' <Albrecht.Schwarz@alcatel-lucent.com>
References: <201006081238.01920.carsten.gross@1und1.de> <201006091733.47767.carsten.gross@1und1.de> <F4562D4585113D42AC08DC47FDEC49B0028869E3@FRVELSMBS23.ad2.ad.alcatel.com> <201006141118.34137.carsten.gross@1und1.de>
In-Reply-To: <201006141118.34137.carsten.gross@1und1.de>
Date: Mon, 14 Jun 2010 17:05:16 +0300
Message-ID: <4c1637a8.698fd80a.0e9b.73c4@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AcsLopQ/FMfd7563QEupnICj3kdrawAJ8LFg
Content-Language: en-us
Cc: avt@ietf.org, mmusic@ietf.org
Subject: Re: [AVT] G.726 payload bitorder (RFC 3551) in current implementations
Precedence: list

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

> -----Original Message-----
> From: Carsten Gross [mailto:carsten.gross@1und1.de]
> Sent: Monday, June 14, 2010 12:19 PM
> To: Schwarz Albrecht
> Cc: Roni Even; avt@ietf.org; mmusic@ietf.org
> Subject: Re: [AVT] G.726 payload bitorder (RFC 3551) in current
> implementations
> 
> Albrecht,
> 
> Am Donnerstag, 10. Juni 2010, um 11:59:24 schrieb Schwarz Albrecht:
> > The SDP O/A looks OK from my perspective.
> > - Both SIP UA's agree to use G726-32 (RFC 3551) as single audio
> format.
> 
> 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 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?)-
> 
> 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
> 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

[AVT] G.726 payload bitorder (RFC 3551) in curren… Carsten Gross
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Schwarz Albrecht
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Roni Even
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Schwarz Albrecht
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Carsten Gross
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Schwarz Albrecht
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Roni Even
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Carsten Gross
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Schwarz Albrecht
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Carsten Gross
Re: [AVT] G.726 payload bitorder (RFC 3551) in cu… Roni Even