MIME-Version: 1.0
References: <cf07ae24c436f92769f9289d208f01846ebe8826.camel@sipsolutions.net>
In-Reply-To: <cf07ae24c436f92769f9289d208f01846ebe8826.camel@sipsolutions.net>
From:   Vadim Yanitskiy <axilirator@gmail.com>
Date:   Wed, 10 Apr 2019 13:35:52 +0700
Message-ID: <CAPEnp=bHTVARr7WA9Qkq4=y7kk8_FLWhrkqKOEXubMO4X=BHCw@mail.gmail.com>
Subject: Re: gsmtap design/extensions?
To:     Johannes Berg <johannes@sipsolutions.net>
Cc:     Harald Welte <laforge@gnumonks.org>,
        OpenBSC Mailing List <openbsc@lists.osmocom.org>,
        Sean Tranchetti <stranche@codeaurora.org>, radiotap@netbsd.org,
        Dan Williams <dcbw@redhat.com>, netdev@vger.kernel.org,
        linux-wireless@vger.kernel.org,
        Aleksander Morgado <aleksander@aleksander.es>,
        Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>,
        =?UTF-8?Q?Bj=C3=B8rn_Mork?= <bjorn@mork.no>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-wireless-owner@vger.kernel.org
Precedence: bulk

Hello Johannes,

FYI, there already was a discussion about GSMTAPv3:

https://www.youtube.com/watch?v=vum9jzavZi0&list=PL07C78AF831FFE8F9&index=10

but unfortunately, nobody has invested time into this (yet?).

> 1) Why the design with encapsulating it in UDP?

This gives us a possibility to "demux" multiple GSMTAP streams on the
receiving side, e.g. if you are running multiple processes.

> 2) The format of gsmtap doesn't seem very extensible [...]

ACK. I definitely support the idea of using TLVs.

With best regards,
Vadim Yanitskiy.