FreeCalypso > hg > themwi-system-sw

comparison README @ 178:b259e2722485

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
README: update for current status
author Mychaela Falconia <falcon@freecalypso.org>
date Thu, 09 Mar 2023 13:08:31 -0800
parents b7cd66acb123
children
comparison
equal deleted inserted replaced
177:a851bde42d82 178:b259e2722485
32 process is themwi-sip-in; this daemon process listens on UDP port 5060, 32 process is themwi-sip-in; this daemon process listens on UDP port 5060,
33 accepts SIP calls from BulkVS (ultimately coming from global worldwide PSTN) 33 accepts SIP calls from BulkVS (ultimately coming from global worldwide PSTN)
34 and turns them into GSM MT calls in MNCC format, going through themwi-mncc 34 and turns them into GSM MT calls in MNCC format, going through themwi-mncc
35 and ultimately to OsmoMSC. 35 and ultimately to OsmoMSC.
36 36
37 * These inbound calls per the previous bullet point also include fully working 37 * Our outbound call gateway is themwi-sip-out, serving as a counterpart to
38 voice path, with our themwi-mgw transcoding the two RTP streams (one in each 38 themwi-sip-in. All GSM MO calls are initially handled by themwi-mncc, which
39 direction) between the original GSM 06.10 codec on the GSM side and G.711 39 decides (based on the dialed number) whether to switch the call locally
40 PCMU or PCMA on the PSTN-via-SIP side. This voice call gateway includes 40 (calling another ThemWi GSM phone) or to pass it to themwi-sip-out. The
41 working DTMF support: START DTMF and STOP DTMF commands from GSM phones pass 41 latter process turns outbound calls into SIP and sends them to BulkVS, and we
42 through OsmoMSC, themwi-mncc and themwi-sip-in to themwi-mgw, and the latter 42 are successfully able to call any PSTN destination anywhere in the +1 country
43 process injects in-band DTMF tones into the G.711 RTP stream that is otherwise 43 code. (themwi-sip-out has provisions for international routes too, but we
44 generated by transcoding from GSM voice codecs. 44 haven't set up any yet.)
45
46 * These inbound and outbound calls per the previous two bullet points also
47 include fully working voice path, with our themwi-mgw transcoding the two RTP
48 streams (one in each direction) between the original GSM 06.10 codec or
49 GSM 06.60 EFR codec on the GSM side and G.711 PCMU or PCMA on the PSTN-via-SIP
50 side. This voice call gateway includes working DTMF support: START DTMF and
51 STOP DTMF commands from GSM phones pass through OsmoMSC, themwi-mncc and
52 themwi-sip-{in,out} to themwi-mgw, and the latter process injects in-band DTMF
53 tones into the G.711 RTP stream that is otherwise generated by transcoding
54 from GSM voice codecs.
45 55
46 The following functionality remains to be implemented: 56 The following functionality remains to be implemented:
47 57
48 * As a counterpart to themwi-sip-in, there will be another process named 58 * The only GSM codecs currently supported are the original FR (GSM 06.10) and
49 themwi-sip-out that will serve as a gateway for outbound calls, going from 59 EFR (GSM 06.60). At some point it would be nice to add support for AMR and
50 GSM MO MNCC to outside PSTN via SIP. The outbound SIP call functional part 60 maybe even HR1, purely for demonstration of its poor voice quality.
51 is already implemented in test prototype form in sip-manual-out.
52 61
53 * Right now themwi-mgw supports only the original FR1 codec (GSM 06.10) on the 62 * The Presiding High Priestess of Themyscira Wireless has a desire to implement
54 GSM side; the Mother's desire is to also support EFR codec as a high priority, 63 in-band GSM 08.62 TFO inside our G.711 RTP interface to outside PSTN. Right
55 and maybe some time later AMR as a lower priority. 64 now if a call is connected between a ThemWi GSM phone on one end and another
65 GSM phone on some other network anywhere else in the world, an undesirable
66 tandem transcoding takes place: two lossy GSM speech codecs run in tandem,
67 one on the ThemWi GSM leg of the call and another on the distant GSM network's
68 leg, with a G.711 64 kbps connection in between. If we implement GSM 08.62
69 TFO inside our G.711 RTP interface which we present to the outside world, we
70 shall achieve TFO calls at least between ThemWi and any other community GSM
71 networks using our software, and maybe even between ThemWi and some legacy
72 commercial GSM networks, if any still remain in parts of the world that are
73 accessible to us.
74
75 * No work whatsoever has been done on SMS as of yet - all of our ThemWi work so
76 far has been in support of voice call functionality only. Adding SMS support
77 will require 3 major areas of work:
78
79 1) We will need to climb the learning curve and assess the current state of SMS
80 support in Osmocom CNI software.
81
82 2) We'll have to find a USA PSTN connectivity provider who supports P2P SMS: if
83 we are operating a GSM network and providing mobile phone service to human
84 end users, any SMS usage in such scenario MUST be classified as P2P rather
85 than A2P. However, gaining access to P2P SMS in USA telecom environment is
86 currently very difficult (every major provider forcibly imposes A2P
87 misclassification with no option of P2P correct classification), in stark
88 contrast to very easy and cheap access to voice PSTN with NANP phone numbers.
89
90 3) When and if we find that necessary USA PSTN connectivity provider with P2P
91 SMS provision, we will need to implement whatever software will be needed to
92 interconnect it with an OsmoCNI GSM network, likely a custom SMSC.
56 93
57 Differences from osmo-sip-connector 94 Differences from osmo-sip-connector
58 ----------------------------------- 95 -----------------------------------
59 96
60 In the Osmocom community, the "standard" (or generally accepted) way to connect 97 In the Osmocom community, the "standard" (or generally accepted) way to connect