Initial Suggestion | Merging osmo-sim-auth and PySIM and update on MNCC with OsmocomBB
Greetings, Congrats on OsmoCon 2017! I have been working with OsmocomBB, osmo-sim-auth, mncc-python projects in Osmocom. I would like to contribute some code snippets with your acceptance. 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? Reason: 1. Solves some mailing list questions: Some questions on mailing list are pertaining sending voice from PC to phone and receive. 2. Useful for test cases: In the future, if 'gsm-efr' codec is implemented, we can use these snippets and send audio with gsm-efr sample, instead of connecting to LCR (Am I correct?) *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. So I faced the issue of voice packets getting dropped, but that was just twice/thrice and then it did not give me any trouble (I'm not sure how it got fixed), I could hear *clear* voice gsm-fr on the called party cell phone. *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? My apologies, if my understanding is incorrect, I just tried to reverse engg. from code and GSM codec available online! 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). 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? Files modified: 1. SIM.py - Added more API's. 2. osmo-sim-auth.py - Options parser. Thanks, Gerard.
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. So I suggest we move the existing mncc-python repository into gerrit, and then you can submit whatever you think is missing in mncc-python? 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?
The way how to properly solve this (normally) is that Layer1 is sending 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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald, No problem. I totally understand thanks for the reply!
So I suggest we move the existing mncc-python repository into gerrit, and then you can submit whatever you think is missing in mncc-python?
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.
A general suggestion (independent of Osmocom): Please always put license information in your code.
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)
If you work on existing code, then please properly clone the original repository and then add your patches on top of it.
Yes, my apologies I did clone from git. However I must have messed up.
The way how to properly solve this (normally) is that Layer1 is sending something like "ready to send (RTS) indications" to Layer2 L1CTL doesn't have this so far, Please also keep future osmocom-bb related questions to the 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.
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.
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 <laforge@gnumonks.org> 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.
So I suggest we move the existing mncc-python repository into gerrit, and then you can submit whatever you think is missing in mncc-python? 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?
The way how to properly solve this (normally) is that Layer1 is sending 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 <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================ ================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On Tue, May 30, 2017 at 08:53:56PM -0700, Gerard Lawrence Pinto wrote:
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.
osmo-sim-auth is on gerrit already, seems to have been there for a while already. For the record, how to use gerrit: http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit osmo-sim-auth patches: https://gerrit.osmocom.org/#/q/project:osmo-sim-auth ~N
participants (3)
-
Gerard Lawrence Pinto -
Harald Welte -
Neels Hofmeyr