Hi Harald, No problem. I totally understand thanks for the reply! Yes, please thanks! As far as I remember there was just 1 issue when I used mncc-python with OsmocomBB on real network. I can confirm this again and push the fix there if it still exists. So you can verify it accordingly. Ok I wasn't aware of this protocol. I read and understood that I need to include GNU PL and cite if a 3rd party library is used (also check its license conditions) If I'm contributing to an existing then keep the original license intact (also check its conditions) Yes, my apologies I did clone from git. However I must have messed up. something like "ready to send (RTS) indications" to Layer2 baseband-devel list, thanks! Very interesting reply, thanks! Sure baseband-devel list, I was thinking the same that it should have been there, so other developers would be aware of it. Yes, please thank you! Sorry about not maintaining history. I have just added other SIM card related API's like fetch - IMSI, LAI, ICCID write LOCI etc. (A full fledged sim reader/writer of a SIM card) Let us keep it in osmo-sim-auth for now. If it is accepted by Osmocom, then later can be merged with Pysim with a different executable? (Although it was built for programmable SIM card - agreed) We can discuss! Thanks, Gerard On Mon, May 29, 2017 at 12:51 AM, Harald Welte &lt;laforge(a)gnumonks.org&gt; wrote: > Hi Gerard, > > sorry for the delayed response, sometimes there are simply too many > tasks and mails to handle :/ > > On Fri, May 19, 2017 at 10:28:56PM -0700, Gerard Lawrence Pinto wrote: > > Congrats on OsmoCon 2017! > > thanks! > > > I have been working with OsmocomBB, osmo-sim-auth, mncc-python > > projects in Osmocom. > > great. The important part is now to make sure those changes don't live > somewhere out there but to think how they can be merged mainline! > > > To begin with I have committed: > > I) MNCC with OsmocomBB - *https://github.com/ > GerardPinto/call-control-mncc-sap > > <https://github.com/GerardPinto/call-control-mncc-sap>* (Has both > > implementations in Python and C + Tested voice with gsm-fr with gsm audio > > file - works great). > > - Some of which can be committed to mncc-python? (In order to support > > MNCC with OsmocomBB too) Although, Harald told me it was built for > OpenNITB > > - I'm not sure, the relevance of this contribution to this repo? > > MNCC should be virtually the same, whether on OsmocomBB or on OsmoNITB > (or now OsmoMSC). Let's avoid having different implementations and > different repositories. At least regarding the python code, please > submit your changes to mncc-python > > We generally try to avoid fragmentation of code but want to have one > implementation of a given functionality within the project. So what's > needed is the knowledge of what exactly is missing or needs > modification/improvement in mncc-python, not another implementation with > unclear status on what are advantages/disadvantages of either of them. > > How does that sound? > > A general suggestion (independent of Osmocom): Please always put license > information in your code. Otherwise it is not clear if anyone is able > to use it (and under what terms). > > > *Issues faced*: File: l23api.c | function: l1ctl_rx_traffic_req() > > 264 bits (33 bytes) of voice codec are interleaved into 456 bits. The > DAC, > > ciphering/deciphering , RF etc. work on 114 bits at a time so, 114 x 4 = > > 456. > > So Layer23 sends 4 - 114 bits into the queue to Layer1 in function => > > l1ctl_rx_traffic_req > > *Code*: num = l1a_txq_msgb_count(&l1s.tx_queue[L1S_CHAN_TRAFFIC]) > > if num > 4 dropping traffic frame. (114 x 4) > > The code above indicates if queue has any (114 x 4) bits drop the > incoming > > voice request. > > Well, GSM is a TDMA system and everything has to happen with regard to > the TDMA clock as defined by the BTS (clock master). So you cannot > send voice frames faster than the TDMA clock is transmitting them. > > > *My Question is*: If I happened to send voice packets 33 bytes really > fast. > > There should be some kind of buffer rather than a check (Code) and drop > > frame? - OR this case can never happen? > > something like "ready to send (RTS) indications" to Layer2, and Layer2 > then knows it has to send another frame. This way, the timing is > defined by L1. However, as there is latency between L1 and L2 (serial > line, operating system scheduling, ...) there actually needs to be a bit > of a buffer or an "advancement" of the RTS indications to compensate for > that. > > L1CTL doesn't have this so far, but it would of course be appreciated if > somebody would make it more robust and contribute related patches. > > Please also keep future osmocom-bb related questions to the > baseband-devel list, thanks! > > > II) osmo-sim-auth with added other SIM related API's (still needs code > > clean up, SIM response check, code re-usable, README.md etc,) > > * https://github.com/GerardPinto/osmo-sim-auth > > <https://github.com/GerardPinto/osmo-sim-auth> * > > - I did check out PySIM (I think I can add some code to the existing > > repository, with your permission). > > If you work on existing code, then please properly clone the original > repository and then add your patches on top of it. That way one can > browse the commit log and clearly look ad individual patches. I'm > unable to figure out what you did by looking at your repository, as you > appear to have imported an unknown version of osmo-sim-auth without > cloning the original repository and keeping history. > > > Could you please let me know if my osmo-sim-auth repo? If it is correct > to > > combine with PySIM, with the changes done below? > > I'm happy to review it once there is a repo based on the original one > with change sets to review. We can also move osmo-sim-auth to gerrit so > you can submit your patches there. But in order to do that, you would > also have to do a proper clone of the original repo and implement your > changes as commits on top. > > Regards, > Harald > -- > - Harald Welte &lt;laforge(a)gnumonks.org&gt; > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) >