[asterisk-dev] Which steps to add Clearmode (rfc4040) passthrough support ?

[Matt Fredrickson]

It seems like this question has come up once or twice in the past 10
years or so.  Replies are inline, below.

On Thu, Mar 21, 2019 at 4:31 AM Olivier <oza.4h07 at gmail.com> wrote:
>
> Hello,
>
> I'm working on request to support SIP trunking with IAD boxes connected to legacy PBXs.
> Those PBXs are using ISDN for dial-in-only remote management.
>
> For successful management sessions, IADs require so-called Clearmode support (rfc4040).
> In my target use-case, a management session involves the following devices:
>
> Admin PC ----  ISDN modem ---- IAD --- Asterisk ---- IAD --- PBX
>
> In this use-case, only Clearmode passthrough is needed as ISDN/Clearmode SIP conversion is done by IAD devices but as Asterisk also supports ISDN, "Clearmode gateway-ing" can help other use cases.
>
> From rfc4040, an example SDP is as follows:
> audio/clearmode; ptime=10
>
> m=audio 12345 RTP/AVP 97
> a=rtpmap:97 CLEARMODE/8000
> a=ptime:10
>
> Also from rfc4040:
> "Clearmode does not use any encoding or decoding.  It just provides packetization.
>
> Clearmode assumes that the data to be handled is sample oriented with one octet (8bits) per sample.  There is no restriction on the number of samples per packet other than the 64 kbyte limit imposed by the IP protocol.  The number of samples SHOULD be less than the path maximum transmission unit (MTU) minus combined packet header length.  If the environment is expected to have tunnels or security encapsulation as part of operation, the number of samples SHOULD be reduced to allow for the extra header space.
>
> The payload packetization/depacketization for Clearmode is similar to the Pulse Code Modulation (PCMU or PCMA) handling described in RFC3551 [5].  Each Clearmode octet SHALL be octet-aligned in an RTP packet.  The sign bit of each octet SHALL correspond to the most significant bit of the octet in the RTP packet."
>
>
> 1. Would Clearmode passthough be a welcome addition ? If positive, which are the best stack candidates (pjsip, cna_sip, chan_pri, ...) for it ?

You probably want to have integration with the SIP channel driver,
chan_pjsip, as well as the traditional line interface driver
chan_dahdi.

> 2. Is passthough support much simpler than full support (gateway and passthrough), taking testing into account ?

Gatewaying will probably require changes to chan_dahdi and other parts
of Asterisk to ensure that no audio manipulation (audio manipulation,
such as echo cancellation) occurs.

> 3. What could be the basics steps for such addition ?

There's a good possibility that you'll want to start with the SIP side
of the work.  This would entail adding support in Asterisk's RTP code
for parsing CLEARMODE type SDP.  You're probably going to need to add
support for it as a separate codec in Asterisk as well to ensure it
doesn't get mapped to something that might be encoded/decoded via
sound manipulation routines (such as ULAW or ALAW).  You'll need to
extend chan_pjsip to support this as an additional format/codec as
well.

For gateway support, you'll probably need to modify chan_dahdi to
support that as one of its native formats, and make sure it does
everything necessary to ensure that audio manipulation inside the
DAHDI stack doesn't occur as well (the above mentioned echo canceller
code, and perhaps other things).

That's the way I'd begin at least.

Good luck, and best wishes!

-- 
Matthew Fredrickson
Digium - A Sangoma Company | Asterisk Project Lead
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA