https://projects.osmocom.org/https://projects.osmocom.org/favicon.ico?16647414092016-08-09T12:15:17ZOpen Source Mobile CommunicationsOsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=20192016-08-09T12:15:17Zlaforge
<ul><li><strong>Assignee</strong> set to <i>neels</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Urgent</i></li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=20322016-08-09T14:56:02Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>starting to find my way around 3G voice support:</p>
<ul>
<li>Our libmsc must not access lchans and so forth directly, but<br /> issue assignment requests to establish calls -- firstly within<br /> osmo-nitb as a function call. For 3G, this will junction to a RAB<br /> Assignment, for 2G ultimately to a BSSMAP Assignment Request<br /> on the to-be-done A-interface.</li>
</ul>
<ul>
<li>Similarly to osmo-bsc standalone operation, we will operate an<br /> osmo-bsc-mgcp proxy to relay RTP streams.</li>
</ul>
<ul>
<li>libmsc must manage RTP ports, probably by configuring<br /> osmo-bsc-mgcp to connect to e.g. a freeswitch port, or back to<br /> itself in case of a local call.</li>
</ul>
<p>Starting to find my way around the details of this task...</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=20542016-08-15T19:44:48Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>status: not really started yet, am first getting the sysmocom/iups and sysmocom/cscn<br />branches synced to openbsc master and verifying that things still work.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21012016-08-30T12:07:58Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/1576">Feature #1576</a>: consider using hLayer2 as a pointer storage</i> added</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21032016-08-30T12:08:04Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-2 status-1 priority-1 priority-lowest" href="/issues/1576">Feature #1576</a>: consider using hLayer2 as a pointer storage</i>)</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21052016-08-30T12:08:16Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-2 priority-default closed" href="/issues/1594">Feature #1594</a>: Split of BSC part from CoreNITB part</i> added</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21332016-09-13T15:49:12Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>20</i></li></ul><p>General status update: I'm moving forward slowly, some problems are<br />sorted out, others are being solved.</p>
<p>I'm testing with both the ip.access nano3G and the femto-X we<br />have in the office.</p>
<p>In summary:</p>
<ul>
<li>RAB Assignment seems to work on femto-X, still fails on nano3G.</li>
<li>Paging for a voice call seems to work on femto-X, still fails on nano3G<br /> (nano3G reboots as soon as it receives a Paging for voice, though<br /> it should be identical to a paging for SMS; difference not pinpointed yet.)</li>
<li>next up:
<ul>
<li>after successful Paging on femto-X, continue with a RAB Assignment.</li>
<li>after successful RAB Assignment on femto-X, continue with RTP stream setup.</li>
<li>try to get the nano3G to work the same way as the femto-X already does.<br /> (we'd like to publish 3G traces preferably by using the nano3G.)</li>
</ul>
</li>
<li>In other news:
<ul>
<li>SMS state machine apparently needs improvement for 3G</li>
<li>Found a cleanup bug on IuRelease that needs fixing</li>
</ul></li>
</ul>
<a name="Details"></a>
<h1 >Details...<a href="#Details" class="wiki-anchor">¶</a></h1>
<p>The first step towards voice on 3G is to have a successful RAB assignment.<br />The signalling up to that point is mostly working (except partial Paging failure<br />on the nano3G).</p>
<p>I start up an osmo-bsc_mgcp (which is thus becoming a misnomer, since it is<br />now talking to an RNC and not a BSC. It should possibly be called 'osmo-mgcpgw'<br />or something similar instead).</p>
<p>I am so far patching up hacks to understand and probe how things work,<br />in the openbsc:neels/cscn and neels/cscn_ghost_call branches.<br />My first step is to obtain a pcap trace with an RTP connection.</p>
The hacks:
<ul>
<li>Configured an mgcp queue to send commands to the MGCP GW from osmo-cscn,<br /> the mgcp config is blindly placed in struct gsm_network so far.</li>
<li>hardcoded mgcp gw IP address in:
<ul>
<li>RAB Assignment TransportLayerAddress IE</li>
<li>MGCP queue from osmo-cscn to MGCP GW</li>
</ul>
</li>
<li>hardcoded mgcp CRCX message.</li>
<li>mncc_builtin.c hack to try and establish only one half of a call</li>
</ul>
<p>There are several "frontiers" to move forward:</p>
<a name="SMS"></a>
<h2 >SMS<a href="#SMS" class="wiki-anchor">¶</a></h2>
<p>SMS delivery employs Paging like for voice calls, so this serves as<br />a nice comparison for Paging.</p>
<p>(SMS probably belongs in a separate issue)</p>
<p>Both femto cells:<br />I notice that Paging only succeeds when the phone has Iu-Released.<br />When SMS'ing to self, there is one unsuccessful Paging:<br />A Paging is sent, but since the UE is still Iu-attached from sending<br />the SMS just a second ago, there is no Paging Response.<br />When the UE releases a few seconds later, the next Paging attempt<br />succeeds, and with the Paging Response received, the SMS is delivered.</p>
<p>Thus for Iu, Paging should apparently be skipped when a UE connection<br />context is already established. We should simply send signalling<br />and not rely on a Paging Response to continue in the state machine.</p>
<p><strong>nano3G:</strong><br />SMS seem to be partly unreliable on the nano3G in that SMS to another<br />UE aren't always delivered, and I see in the CSCN log:<br /><pre>
20160913144048249 <0022> gsm0411_smc.c:467 SMC(0) message MNSMS-REL-REQ received in state WAIT_CP_ACK
20160913144048249 <0022> gsm0411_smc.c:332 SMC(0) cannot release yet current state: WAIT_CP_ACK
</pre></p>
<p><strong>femto-X:</strong><br />On the femto-X, Paging works well, but I notice that only one SMS is delivered per<br />InitialUE message, i.e. UE is paged, replies, one SMS is delivered,<br />nothing happens until Iu-Release in a few seconds, then UE is paged<br />again, next SMS is delivered... and so on. Technically, the CSCN could<br />pump any number of SMS per successful Paging.</p>
<p>So it seems the state machine concerning SMS on 3G signalling is not<br />yet accurate.</p>
<a name="Voice-Call"></a>
<h2 >Voice Call<a href="#Voice-Call" class="wiki-anchor">¶</a></h2>
<p>Calling self or an unknown extension is usually thwarted by signalling<br />(CC Release) before any part of the call is established. Thus I have<br />two ways of testing:</p>
<p>One is a hack that doesn't care about the second half of the call and<br />allows to establish an RTP stream to the first half without interfering;<br />I call it a "ghost call".</p>
<p>The other is actually having two phones, which involves Paging.</p>
<a name="Calling-a-second-phone"></a>
<h3 >Calling a second phone<a href="#Calling-a-second-phone" class="wiki-anchor">¶</a></h3>
<p>First off, since we have a hardcoded Ki for 3G auth, I set up a second<br />SIM card with the same Ki and picked a Samsung Galaxy SII from the<br />cupboard. This allows me to have two UE subscribed at the same time.</p>
<p><strong>nano3G:</strong><br />When trying to call one UE from the other UE, the<br />nano3G doesn't like the Paging. Though the SMS Paging seems to work<br />fine, the Paging for a voice call for some reason makes the nano3G<br />reboot immediately. It does print some logs, but so far I haven't<br />understood the cause, since the Paging should be similar to SMS:<br /><pre>
Sep 13 12:06:17.702 [UEContext-15] RANAP CommonId from CSDomain
Sep 13 12:06:17.702 [UEContext-15] HNB-GW> RANAP CommonId, CSDomain
Sep 13 12:06:17.702 [UEContext-15] RANAP CommonId provided IMSI 901990000000038
Sep 13 12:06:17.818 [UEContext-15] URSL> UplinkDirectTransfer
Sep 13 12:06:17.818 [UEContext-15] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 30
Sep 13 12:06:17.823 [UEContext-15] RUA DirectTransferInd, domain 0, RANAP length 19
Sep 13 12:06:17.824 [UEContext-15] HNB-GW> RANAP DirectTransfer CSDomain
Sep 13 12:06:17.828 [3GAP-3] C3GAP::Send uRSL msg id 7
Sep 13 12:06:18.023 [UEContext-15] RUA DirectTransferInd, domain 0, RANAP length 76
Sep 13 12:06:18.026 [UEContext-15] RANAP RAB Assignment from CSDomain
Sep 13 12:06:18.026 [UEContext-15] HNB-GW> RANAP RABAssignmentRequest, CSDomain
Sep 13 12:06:18.035 [3GAP-3] C3GAP::Send uRSL msg id 13
Sep 13 12:06:18.046 [RANAP ConnectionlessInd] RANAP Paging provided IMSI 262778026147135
Sep 13 12:06:18.046 [RANAP] Paging 262778026147135
Sep 13 12:06:18.050 [3GAP-3] C3GAP::Send uRSL msg id 20
Sep 13 12:06:18.060 [UEContext-15] URSL> UserPlaneCfgRequest
Sep 13 12:06:18.062 [3GAP-3] C3GAP::Send uRSL msg id 22
Sep 13 12:06:18.119 ERR: [CInterface] Recv from 127.0.0.1 failed, closing.
Sep 13 12:06:18.119 [3GAP-3] Connection from id 'LOCAL' failed
Sep 13 12:06:18.120 [3GAP-3] Stream from id 'LOCAL' failed
Sep 13 12:06:18.120 [URSLManager-4] Sending HNBDeregister to HNB-GW
Sep 13 12:06:18.122 [3GAP-3] C3GAP::Send uRSL msg id 9
Sep 13 12:06:18.123 [UEContext-15] UE context destroyed. SRNTI 166754, ACUEId 9, IuH CtxtId 2342
Sep 13 12:06:18.123 [UEContext-15] Destroyed UEContext-15, Remaining URSLManager-4 UEContext-8 MIBCnx-1 3GAP-3 IuhClient-12 SysAgent-2
Sep 13 12:06:18.123 [IuhClient-12] Iuh Connection close request
Sep 13 12:06:18.123 [IuhClient-12] Dropping connection with 10.9.1.120, socket 20
Sep 13 12:06:19.124 [URSLManager-4] Iuh disconnected
Sep 13 12:06:19.125 [IuhClient-12] SCTP stats file read: Shutdowns 1 to 2; Aborts 0 to 0
Sep 13 12:06:19.125 [SysAgent-2] SctpAssociationClosures incremented by 1
Sep 13 12:06:19.126 [IuhClient-12] Destroyed IuhClient-12, Remaining URSLManager-4 UEContext-8 MIBCnx-1 3GAP-3 SysAgent-2
Sep 13 12:06:19.126 [3GAP-3] URSL unavailable, previously closed
Sep 13 12:06:19.126 [MIBCnx-1] Update localHnbGwConnectionStatus in MIB: 0
Sep 13 12:06:19.128 [MIBCnx-1] Update hnbGwConnectionState in MIB: 0
Sep 13 12:06:19.128 [URSLManager-4] Going to clear the DNS Info
Sep 13 12:06:19.129 [UEContext-8] REL_IND from Manager
Sep 13 12:06:19.130 [UEContext-8] UE context destroyed. SRNTI 166754, ACUEId 3, IuH CtxtId 2342
Sep 13 12:06:19.130 ERR: [UEContext-8] UE Deregister was pending but not sent
Sep 13 12:06:19.130 [UEContext-8] Destroyed UEContext-8, Remaining URSLManager-4 MIBCnx-1 3GAP-3 SysAgent-2
Sep 13 12:06:19.130 [URSLManager-4] Destroyed URSLManager-4, Remaining MIBCnx-1 3GAP-3 SysAgent-2
Sep 13 12:06:19.131 [3GAP-3] Connection with 3GAP at 127.0.0.1 dropped
Sep 13 12:06:20.131 [3GAP-3] Destroyed 3GAP-3, Remaining MIBCnx-1 SysAgent-2
Sep 13 12:06:30.210 ERR: [CInterface] Recv from 127.0.0.1 failed, closing.
Sep 13 12:06:30.210 [MIBCnx-1] Connection from id '' failed
Connection to 10.9.1.168 closed by remote host.
Connection to 10.9.1.168 closed.
</pre></p>
<p><strong>femto-X:</strong><br />Paging successfully completes for a voice call (without code<br />modifications).</p>
<p>After a successful Paging, the 3G code doesn't yet lead into a RAB Assignment,<br />this is the next thing I want to get to work.</p>
<a name="Ghost-call"></a>
<h3 >Ghost call<a href="#Ghost-call" class="wiki-anchor">¶</a></h3>
<p>When hacking the mncc_builtin.c to establish only the first half of a call,<br />the CSCN sends a RAB Assignment with the IPv4 address and port<br />of my osmo-bsc_mgcp gateway.</p>
<p>I needed a patch in osmo-iuh to enable the port part of a TransportLayerInformation<br />IE sent in a RAB-Assignment (was #if 0'd to be port 1 always).</p>
<p>I also send a CRCX message to the mgcp gw to enable the RTP port.</p>
<p><strong>nano3G:</strong><br />Firstly, this needed a patching for the nano3G to send the<br />32bit address format in the RAB Assignment.<br />I see connections made to an RTP port of the MGCP GW.<br />The MGCP GW posts some seemingly neglectable error ("Failed to send dummy packet").<br />After a timeout of some seconds, the RAB Activation is nacked by the nano3G,<br />with an Outcome message indicating cause "misc - unspecified failure".<br />The dummy packet error seems to be irrelevant though (see below).</p>
<p>MGCP GW logs on the nano3G:<br /><pre>
20160913172326216 <000b> mgcp_main.c:237 VTY at 127.0.0.1 4243
20160913172326216 <000b> mgcp_main.c:291 Configured for MGCP.
20160913172521369 <000b> mgcp_protocol.c:662 Configuring RTP endpoint: local port 0
20160913172521369 <000b> mgcp_protocol.c:662 Configuring RTP endpoint: local port 0
20160913172521369 <000b> mgcp_protocol.c:872 Creating endpoint on: 0x1 CI: 1 port: 16002/4002
20160913172521369 <000b> mgcp_network.c:120 Failed to send dummy RTP packet: Invalid argument on: 0x1 to 0.0.0.0:0
20160913172521369 <000b> mgcp_protocol.c:160 Generated response: code: 200 for '200 1234 OK
I: 1
v=0
o=- 1 23 IN IP4 10.9.1.120
s=-
c=IN IP4 10.9.1.120
t=0 0
m=audio 16002 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=ptime:20
'
20160913172521625 <000b> mgcp_network.c:752 Found BTS for endpoint: 0x1 on port: 1024/0 of 10.9.1.168
20160913172521625 <000b> mgcp_network.c:442 Initializing stream on 0x1 SSRC: 683016449 timestamp: 0 pkt-duration: 160, from 10.9.1.168:1024 in 1
</pre></p>
<p>nano3G trace log after the RAB Assignment failure:<br /><pre>
Sep 13 15:25:21.253 [UEContext-9] RANAP CommonId from CSDomain
Sep 13 15:25:21.253 [UEContext-9] HNB-GW> RANAP CommonId, CSDomain
Sep 13 15:25:21.254 [UEContext-9] RANAP CommonId provided IMSI 901990000000038
Sep 13 15:25:21.369 [UEContext-9] URSL> UplinkDirectTransfer
Sep 13 15:25:21.369 [UEContext-9] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 30
Sep 13 15:25:21.372 [UEContext-9] RUA DirectTransferInd, domain 0, RANAP length 19
Sep 13 15:25:21.373 [UEContext-9] HNB-GW> RANAP DirectTransfer CSDomain
Sep 13 15:25:21.377 [3GAP-3] C3GAP::Send uRSL msg id 7
Sep 13 15:25:21.572 [UEContext-9] RUA DirectTransferInd, domain 0, RANAP length 76
Sep 13 15:25:21.574 [UEContext-9] RANAP RAB Assignment from CSDomain
Sep 13 15:25:21.574 [UEContext-9] HNB-GW> RANAP RABAssignmentRequest, CSDomain
Sep 13 15:25:21.583 [3GAP-3] C3GAP::Send uRSL msg id 13
Sep 13 15:25:21.603 [UEContext-9] URSL> UserPlaneCfgRequest
Sep 13 15:25:21.605 [3GAP-3] C3GAP::Send uRSL msg id 22
Sep 13 15:25:29.732 [SCTP] Setting SCTP heartbeat to 5
Sep 13 15:25:33.645 [UEContext-9] URSL RABAssignmentResponse from UE, CSDomain, Assignment failed, RANAP cause 115
Sep 13 15:25:33.645 [UEContext-9] URSL RABAssignmentResponse from UE, CSDomain, Assignment failed, RANAP cause 115
Sep 13 15:25:51.519 [UEContext-9] URSL> UplinkDirectTransfer
Sep 13 15:25:51.519 [UEContext-9] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 5
Sep 13 15:25:51.522 [UEContext-9] RUA DirectTransferInd, domain 0, RANAP length 23
Sep 13 15:25:51.523 [UEContext-9] HNB-GW> RANAP DirectTransfer CSDomain
Sep 13 15:25:51.527 [3GAP-3] C3GAP::Send uRSL msg id 7
Sep 13 15:25:51.708 [UEContext-9] URSL> UplinkDirectTransfer
Sep 13 15:25:51.708 [UEContext-9] URSL Uplink DirectTransfer from UE, CSDomain, NAS len 2
Sep 13 15:26:01.679 [UEContext-9] URSL IuReleaseRequest
Sep 13 15:26:01.680 [UEContext-9] URSL IuReleaseReq from UE, CSDomain, Iap Cause 1
Sep 13 15:26:01.682 [UEContext-9] RUA DirectTransferInd, domain 0, RANAP length 13
Sep 13 15:26:01.683 [UEContext-9] RANAP IuReleaseCommand
Sep 13 15:26:01.683 [UEContext-9] HNB-GW> RANAP IuRelease, CSDomain
Sep 13 15:26:01.683 [UEContext-9] Sending RUADisconnect to HNB-GW for CSDomain Context 0x926
Sep 13 15:26:01.684 [UEContext-9] Sending RUADisconnect to HNB-GW for CSDomain Context 0x926
Sep 13 15:26:01.691 [3GAP-3] C3GAP::Send uRSL msg id 9
Sep 13 15:26:01.833 [UEContext-9] UEContextRelease from UE
</pre></p>
<p><strong>femto-X:</strong><br />The connection to the MGCP GW seems to be successful here,<br />and femto-X replies with a successful RAB Assignment outcome immediately.</p>
<p>MGCP GW log for femto-X:<br /><pre>
20160913165947123 <000b> mgcp_main.c:237 VTY at 127.0.0.1 4243
20160913165947123 <000b> mgcp_main.c:291 Configured for MGCP.
20160913170100378 <000b> mgcp_protocol.c:662 Configuring RTP endpoint: local port 0
20160913170100378 <000b> mgcp_protocol.c:662 Configuring RTP endpoint: local port 0
20160913170100378 <000b> mgcp_protocol.c:872 Creating endpoint on: 0x1 CI: 1 port: 16002/4002
20160913170100378 <000b> mgcp_network.c:120 Failed to send dummy RTP packet: Invalid argument on: 0x1 to 0.0.0.0:0
20160913170100378 <000b> mgcp_protocol.c:160 Generated response: code: 200 for '200 1234 OK
I: 1
v=0
o=- 1 23 IN IP4 10.9.1.120
s=-
c=IN IP4 10.9.1.120
t=0 0
m=audio 16002 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=ptime:20
'
20160913170101767 <000b> mgcp_network.c:752 Found BTS for endpoint: 0x1 on port: 8000/0 of 10.9.1.11
20160913170101767 <000b> mgcp_network.c:442 Initializing stream on 0x1 SSRC: 1002855813 timestamp: 0 pkt-duration: 160, from 10.9.1.11:8000 in 1
20160913170101768 <000b> mgcp_network.c:376 RTP seqno made a very large jump on 0x1 delta: 10112
20160913170101768 <000b> mgcp_network.c:185 The input timestamp delta is 0 on 0x1 SSRC: 1002855813 timestamp: 8037710 from 10.9.1.11:8000 in 1
20160913170101768 <000b> mgcp_network.c:185 The output timestamp delta is 0 on 0x1 SSRC: 1002855813 timestamp: 8037710 from 10.9.1.11:8000 in 1
</pre></p>
<a name="clean-up-failure"></a>
<h3 >clean up failure<a href="#clean-up-failure" class="wiki-anchor">¶</a></h3>
<p>As a side note:</p>
<p>femto-X: When I fail to encode the RTP port (osmo-iuh patch missing),<br />I see no rejection of the RAB Assignment, but simply an Iu Release.<br />This leads the CSCN into a segfault since some timer is not cleaned up:</p>
<pre>
20160913161416014 <0000> ranap_decoder.c:4055 Decoding message RANAP_Iu_ReleaseCompleteIEs (ranap_decoder.c:4055)
20160913161416014 <0019> iu.c:460 handle_co(dir=2, proc=1)
20160913161416014 <001b> cscn_main.c:461 got IuCS event 2: IU_EVENT_IU_RELEASE
20160913161416014 <001b> iucs.c:87 Looking for IuCS subscriber: link_id 0x6e2fc0, conn_id 1
20160913161416014 <001b> iucs.c:50 0: 901990000000038 Iu link 0x6e2fc0, conn_id 1
20160913161416014 <001b> iucs.c:75 subscribers registered: 1
20160913161416014 <001b> iucs.c:96 Found IuCS subscriber for link_id 0x6e2fc0, conn_id 1
20160913161416014 <001b> iucs_ranap.c:102 IuCS release for 901990000000038
20160913161416014 <0006> mncc_builtin.c:369 (call 80000001) Received message MNCC_REL_IND
20160913161416014 <0006> mncc_builtin.c:272 (call 80000001) Releasing remote with cause 47
20160913161416014 <0006> mncc_builtin.c:52 (call 80000001) Call removed.
20160913161416014 <0006> gsm_04_08.c:3390 receive message MNCC_REL_REQ
20160913161416014 <0001> gsm_04_08.c:3605 (ti 08 sub 40014) Received 'MNCC_REL_REQ' from MNCC in state 3 (MO_CALL_PROC)
20160913161416014 <0001> gsm_04_08.c:1942 starting timer T308 with 10 seconds
20160913161416014 <0001> gsm_04_08.c:1398 new state MO_CALL_PROC -> RELEASE_REQ
20160913161416014 <0019> iu.c:398 Transmitting L3 Message as RANAP DT (SUA link 0x6e2fc0 conn_id 1)
<RANAP_IE>
<id>16</id>
<criticality><ignore/></criticality>
<value>06 83 2D 08 02 81 AF</value>
</RANAP_IE>
<RANAP_IE>
<id>59</id>
<criticality><ignore/></criticality>
<value>00</value>
</RANAP_IE>
20160913161416014 <001a> sua.c:591 Received SCCP User Primitive (N-DATArequest)
20160913161416014 <001a> sua.c:245 sua_link_send(01 00 08 08 00 00 00 34 00 06 00 08 00 00 00 00 01 05 00 08 00 00 03 e8 01 0b 00 1b 00 14 00 13 00 00 02 00 10 40 07 06 83 2d 08 02 81 af 00 3b 40 01 00 00 )
20160913161416014 <0001> gsm_04_08.c:1398 new state RELEASE_REQ -> NULL
20160913161416014 <001a> sua.c:339 (1) state chg ACTIVE->IDLE
20160913161416014 <001e> stream.c:561 connected read/write
20160913161416014 <001e> stream.c:526 sending data
20160913161416014 <001e> stream.c:561 connected read/write
20160913161416014 <001e> stream.c:526 sending data
20160913161416210 <001e> stream.c:561 connected read/write
20160913161416210 <001e> stream.c:509 message received
20160913161416210 <001a> sua.c:1274 sua_srv_conn_cb(): sctp_recvmsg() returned 12
NOTIFICATION 32777 flags=0x0
===> SCTP_SENDER_DRY_EVENT
Program received signal SIGSEGV, Segmentation fault.
rb_insert_color (node=node@entry=0x641098,
root=root@entry=0x7ffff777d010 <timer_root>) at rbtree.c:80
80 if (parent == gparent->rb_left)
(gdb) bt
#0 rb_insert_color (node=node@entry=0x641098,
root=root@entry=0x7ffff777d010 <timer_root>) at rbtree.c:80
#1 0x00007ffff756d0ce in __add_timer (timer=0x641098) at timer.c:65
#2 osmo_timer_add (timer=timer@entry=0x641098) at timer.c:76
#3 0x00007ffff756d128 in osmo_timer_schedule (timer=0x641098, seconds=10,
microseconds=0) at timer.c:98
#4 0x00007ffff756d39c in osmo_timers_update () at timer.c:244
#5 0x00007ffff756d8a9 in osmo_select_main (polling=0) at select.c:188
#6 0x0000000000405ab4 in main (argc=1, argv=0x6dfc40) at cscn_main.c:651
(gdb)
</pre>
<p>Though this only happens when the RTP port is not encoded correctly, we should<br />make sure to properly clean up upon an Iu Release.<br />This should not be a lot of effort.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21442016-09-16T13:32:14Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>20</i> to <i>30</i></li></ul><p>Breaking news: first successful osmocom-3G phone-to-phone voice call!</p>
<p>With the femto-X and using the neels/cscn branch, the first complete<br />voice call with working audio streams in both directions worked out<br />some minutes ago.</p>
<p>Most of the things like IP addresses and port numbers are still pretty<br />hardcoded / hacked and some things are incomplete, but now the road is<br />clear and I can work on making things nice.</p>
<p>The voice call is using the osmo-bsc_mgcp as MGCP-GW to relay the<br />RTP stream from the femto cell back to the femto cell. That means<br />we should be able to connect any RTP src/dst fairly easily.</p>
<p>The ip.access nano3G is still unchanged, i.e. reboots upon Paging,<br />I hope to be able to get it to work the same way as the femto-X<br />does soon.</p>
<p>Anyway, we should be able to publish a pcap with RTP now/soon.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21482016-09-19T00:27:49Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Noticed one possible cause for failures on the nano3G:</p>
<p>Background: on the nano3G upon a HNBAP UE Register, a UE may try to<br />register with a TMSI even though it is seen for the first time.<br />We'd prefer/expect an IMSI. In order to help with development, we have a<br />hack that just accepts UE Registration with a TMSI. We so far don't use any<br />recorded state in the HNBGW anyway.</p>
<p>However, the UE Register Accept contains a context ID that the HNBGW tells<br />the femto cell about. With a TMSI registration, we actually just<br />always return context ID 2342 as part of the hack.</p>
<p>It appears the nano3G uses this context ID, and may fall over the fact<br />that it is the same for any UE registering by TMSI.</p>
<p>So far, incrementing the hacked context ID for each UE hasn't magically<br />solved any problems though, except a nicer log on the nano3G.</p>
<p>With or without duplicate context IDs, I can no longer reproduce the<br />nano3G reboots upon paging for voice. It seems some or other bad value<br />in our messages doesn't always cause the same kind of failure.</p>
<p>Still searching for the bad value/values that stop the nano3G show.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21492016-09-19T01:04:09Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>So far, incrementing the hacked context ID for each UE hasn't magically<br />solved any problems though, except a nicer log on the nano3G.</p>
</blockquote>
<p>I can confirm that when the phones register by IMSI, Paging works on the nano3G.</p>
<p>I manually attempt to register the phones on a real network (and get rejected)<br />to clear the TMSI. Then, when the phones go through our normal hnbgw code to<br />register with a context ID that is valid, the Paging is replied upon.</p>
<p>The paged phone goes on to authenticate and a CC Setup + Call Confirmed is<br />sent. Next would be the RAB Assignment.</p>
<p>However, the RAB Assignment still fails the same way as with the ghost<br />call test, only twice, once for each phone; cause 115 (unspecified-failure):</p>
<pre>
Sep 19 00:40:03.868 [UEContext-11] RANAP RAB Assignment from CSDomain
Sep 19 00:40:03.868 [UEContext-11] HNB-GW> RANAP RABAssignmentRequest, CSDomain
Sep 19 00:40:03.882 [3GAP-3] C3GAP::Send uRSL msg id 13
[...]
Sep 19 00:40:06.476 [UEContext-12] RANAP RAB Assignment from CSDomain
Sep 19 00:40:06.477 [UEContext-12] HNB-GW> RANAP RABAssignmentRequest, CSDomain
Sep 19 00:40:06.488 [3GAP-3] C3GAP::Send uRSL msg id 13
Sep 19 00:40:06.500 [UEContext-12] URSL> UserPlaneCfgRequest
Sep 19 00:40:06.501 [3GAP-3] C3GAP::Send uRSL msg id 22
Sep 19 00:40:15.945 [UEContext-11] URSL RABAssignmentResponse from UE, CSDomain, Assignment failed, RANAP cause 115
Sep 19 00:40:15.946 [UEContext-11] URSL RABAssignmentResponse from UE, CSDomain, Assignment failed, RANAP cause 115
Sep 19 00:40:18.530 [UEContext-12] URSL RABAssignmentResponse from UE, CSDomain, Assignment failed, RANAP cause 115
Sep 19 00:40:18.530 [UEContext-12] URSL RABAssignmentResponse from UE, CSDomain, Assignment failed, RANAP cause 115
</pre>
<p>Some seconds pass between RAB Assignment request and response, and as with<br />the ghost call test, I see some requests on the MGCPGW:</p>
<pre>
20160919023622051 <000b> mgcp_main.c:237 VTY at 127.0.0.1 4243
20160919023622051 <000b> mgcp_main.c:291 Configured for MGCP.
20160919024008710 <000b> mgcp_protocol.c:662 Configuring RTP endpoint: local port 0
20160919024008710 <000b> mgcp_protocol.c:662 Configuring RTP endpoint: local port 0
20160919024008710 <000b> mgcp_protocol.c:872 Creating endpoint on: 0x3 CI: 1 port: 16006/4006
20160919024008710 <000b> mgcp_network.c:120 Failed to send dummy RTP packet: Invalid argument on: 0x3 to 0.0.0.0:0
20160919024008710 <000b> mgcp_protocol.c:160 Generated response: code: 200 for '200 423 OK
I: 1
v=0
o=- 1 23 IN IP4 192.168.0.132
s=-
c=IN IP4 192.168.0.132
t=0 0
m=audio 16006 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=ptime:20
'
20160919024008974 <000b> mgcp_network.c:752 Found BTS for endpoint: 0x3 on port: 1024/0 of 192.168.0.124
20160919024008974 <000b> mgcp_network.c:442 Initializing stream on 0x3 SSRC: 683016465 timestamp: 0 pkt-duration: 160, from 192.168.0.124:1024 in 1
20160919024011520 <000b> mgcp_protocol.c:662 Configuring RTP endpoint: local port 0
20160919024011520 <000b> mgcp_protocol.c:662 Configuring RTP endpoint: local port 0
20160919024011520 <000b> mgcp_protocol.c:872 Creating endpoint on: 0x4 CI: 2 port: 16008/4008
20160919024011520 <000b> mgcp_network.c:120 Failed to send dummy RTP packet: Invalid argument on: 0x4 to 0.0.0.0:0
20160919024011520 <000b> mgcp_protocol.c:160 Generated response: code: 200 for '200 424 OK
I: 2
v=0
o=- 2 23 IN IP4 192.168.0.132
s=-
c=IN IP4 192.168.0.132
t=0 0
m=audio 16008 RTP/AVP 98
a=rtpmap:98 AMR/8000
a=ptime:20
'
20160919024011563 <000b> mgcp_network.c:752 Found BTS for endpoint: 0x4 on port: 1026/0 of 192.168.0.124
20160919024011563 <000b> mgcp_network.c:442 Initializing stream on 0x4 SSRC: 683016450 timestamp: 0 pkt-duration: 160, from 192.168.0.124:1026 in 1
</pre> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21502016-09-19T01:14:03Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Things to do:</p>
<ul>
<li>Transform the HNBGW HNBAP TMSI hack into a proper procedure that registers<br /> a context ID for the new subscriber.</li>
</ul>
<ul>
<li>Find out why the nano3G is discovered by the MGCPGW with IP address and port<br /> but still the nano3G concludes that the RAB Assignment was unsuccessful.<br /> <pre>Found BTS for endpoint: 0x4 on port: 1026/0 of 192.168.0.124</pre></li>
</ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=21842016-10-10T19:26:36Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>30</i> to <i>50</i></li></ul><p>The HNBAP UE Register with TMSI now registers a proper context ID on osmo-hnbgw,<br />which helps testing the nano3G.</p>
<p>MGCP for 3G voice is still in the process of being made configurable.<br />Not tested with calls across cells, only two phones on the same cell.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=22672016-10-18T18:26:10Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>50</i> to <i>60</i></li></ul><p>Added proper parsing of the MGCP responses from the MGCP GW.<br />The audio port number is no longer hardcoded but taken from the CRCX response.<br />IuCS now parses the MGCP GW responses and can evaluate error codes.</p>
<p>Whether any action is needed in case of error codes still needs to be tested.<br />Arguably the call establishment gsm_trans will simply timeout in the usual fashion.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=23402016-11-03T13:47:06Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Still, the biggest show stopper here is that the nano3G persistently refuses to accept<br />RAB Assignments for IuCS.</p>
<p>The log message actually states that the RAB is rejected by the UE, which might<br />be an unintentional implication: if I send the wrong IP address format in the RAB<br />assignment, the nano3G also logs the identical error message. Note "from UE":</p>
<pre>
Oct 20 16:41:03.313 [UEContext-38] URSL RABAssignmentResponse from UE, CSDomain, Assignment failed, RANAP cause 115
</pre>
<p>Attempts to use a Quectel EC20 to analyse the UE side so far failed because our<br />nano3G uses the US 1900 band, which the EC20 so far does not recognise.<br />(The same EC20 successfully produces GSMTAP for the Euro-band sysmocell 5000)</p>
<p>Clarify: is this a Euro-band EC20? Should we buy a quad-band EC20?<br />Is there an AT command to switch bands?</p>
<p>A PDF for the Quectel M10 mentions AT commands to switch bands:<br />AT+QBAND=? / AT+QBAND=PCS_MODE<br />but our EC20 just replies 'ERROR' to those.</p>
<p>The EC20 however is branded as an LTE module that is backwards compatible<br />with UMTS, so possibly the command set is different. We should get hold<br />of an actual EC20 command set manual.</p>
<p>(Other commands like AT+COPS=..., AT+CUSD=..., ATA and ATH however work<br />as expected)</p>
<p>Once the nano3G works we might attempt routing calls between two separate 3G cells.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=23442016-11-03T22:07:55Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>Clarify: is this a Euro-band EC20? Should we buy a quad-band EC20?<br />Is there an AT command to switch bands?</p>
</blockquote>
<p>There is an AT command to switch bands. It is <strong>not</strong> AT+QBAND, but</p>
<pre>
AT+QCFG=“band”[,<bandval>,<ltebandval>,<tdsbandval>[,<effect>]]
</pre>
<p>e.g.<br /><pre>
AT+QCFG="band",0000006c,0,0,0
</pre></p>
<p>and needs a power cycle to take effect.<br />The effect is verified:</p>
<pre>
AT+QCFG="band"
+QCFG: "band",0x6c,0x800d5,0x0
</pre>
<p>Using this, I tried to switch the band, or also enable all bands at the same time<br />(0xff), but so far the EC20 does not see the nano3G cell (i.e. <code>AT+COPS=?</code> doesn't show it).</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=23452016-11-04T00:26:52Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Opened the case, the label says<br />"EC20 / E QA" and smaller: "EC20EA-256-STD / EC20EQAR02AA01E2G"</p>
<p>So I assume its an EC20-E model, i.e. a quad-band<br />according to <a class="external" href="http://www.quectel.com/product/prodetail.aspx?id=84">http://www.quectel.com/product/prodetail.aspx?id=84</a><br />which means that it <strong>should</strong> work.</p>
<p>Tried to find further hints in the AT commands manual.<br />Tried to <code>AT+COPS=?</code> numerous times in case it misses it sporadically.<br />So, I have not yet found out why the EC20 doesn't see the nano3G cell.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=23462016-11-04T00:32:48Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Also took another look at the RAB assignment message itself.<br />The "convenience" here is that the nano3G plainly reboots when it doesn't like a RAB Assignment.</p>
<p>So whichever tiny parameter I tweaked so far to see whether it makes a difference caused the<br />nano3G to reboot right away.</p>
<p>The fact that the nano3G does not reboot and already sends RTP packets to the IP address<br />and port set in the RAB Assignment message makes me assume that our RAB Assignment Request<br />is actually exactly the way it should be.</p>
<p>Right after the RAB Assignment, we echo the same RTP packets back that we receive from the<br />nano3G (works well with the SysmoCell 5000). I tried modifying select parameters there:<br />ssrc id, sequence number, timestamp, to see whether they caused some collision. No effect.</p>
<p>So despite all efforts, so far the nano3G remains stubbornly voiceless.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=23472016-11-04T00:49:57Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>also made sure that the rab ids between CS and PS don't cause collision (of course not)</p>
<p>also tried to not echo back RTPC, only RTP. No difference.<br />The RAB Assignment unsuccessful outcome always follows after six RTP packets,<br />for both of the UEs involved in the call.</p>
<p>BTW, the called=MT UE does not ring / indicate an incoming call yet, nevertheless<br />we do receive RTP packets both from the MO and the MT sides. I'd like to assume<br />that the nano3G thus does all of the RTP up to then, but that is handwavy at best.</p>
<p>Thought experiment: are any of the SDU sizes or other parameters such that the nano3G<br />would feed them to the UE, but the UE would reject them? In that case the very same<br />two UEs should not be able to call each other using the sysmocell 5000 and same params.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=24262016-11-09T16:22:05Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>There has been success with UE-GSMTAP on the nano3G:</p>
<p>They key point is that the EC20-E does not support UMTS 1900 aka B2.<br />However, it does support B5, i.e. UMTS 850.</p>
<p><a href="http://www.quectel.com/product/prodetail.aspx?id=84" class="external">UMTS: B1/B5/B8</a><br /><a class="external" href="https://en.wikipedia.org/wiki/UMTS_frequency_bands">https://en.wikipedia.org/wiki/UMTS_frequency_bands</a></p>
<p>Setting the nano3G onto a B5 frequency worked out:<br />picking DL-ARFCN 4400 resulted in the cell becoming visible to the EC20.</p>
<p>Hence we have nano3G GSMTAP of the RAB-Assignment procedure.<br />The RAB-Assignment however does not go through to the UE...</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=24962016-11-24T16:39:08Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li></ul><p>Still no progress on nano3G RAB.</p>
<p>Directing my attention to <a class="issue tracker-2 status-5 priority-4 priority-high2 closed child" title="Feature: 3G Auth (Closed)" href="https://projects.osmocom.org/issues/1711">#1711</a> / <a class="issue tracker-2 status-5 priority-4 priority-high2 closed" title="Feature: VLR in libmsc, to connect to HLR asynchronously (Closed)" href="https://projects.osmocom.org/issues/1592">#1592</a> now -- the 3G capable VLR.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=29222017-01-24T10:58:36Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li><li><strong>% Done</strong> changed from <i>60</i> to <i>70</i></li></ul><p>We've finally found out how to get the nano3G to accept a CS RAB Assignment!</p>
<p>When we send a RAB Assignment request to the nano3G, it sends a first RTP packet to the specified port.<br />We then echo the same RTP packet back, but we need to <strong>overwrite</strong> the first two payload bytes with 'e400'.</p>
<p>The RAB Assignment message itself seems to be fairly irrelevant.</p>
<p>We've also found out that the nano3G indeed accepts X.213 NSAP for transportLayerAddress,<br />but it needs to be 160 bits long: i.e. the X.213 header '350001' followed by the 32bit<br />encoded IPv4 address, followed by zero bits to fill up 160. Before, we sent only 56 bits.</p>
<p>So far there is no obvious explanation of the 'e400' bytes in the RTP payload.<br />It makes no sense whatsoever when looking at AMR or other RTP payload specs.<br />All we know is that the nano3G rejects RAB Assignments without them.</p>
<p>In summary:</p>
<ul>
<li>3G Voice is working with the sysmocell5000, with two UEs on the same cell.</li>
<li>3G Voice is probably going to work with the nano3G, now that we have a RAB Assignment.<br /> Pending: a test of an actual voice call with two UE subscribed at the same nano3G.</li>
<li>It's possible that the nano3G uses a proprietary RTP payload, find out whether<br /> a nano3G stream forwarded to a sysmocell5000 works.</li>
<li>forwarding voice streams between separate 3G cells is not tested yet.</li>
<li>forwarding voice streams to SIP is not implemented nor tested yet.</li>
</ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=29262017-01-24T15:09:32Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The first RTP payload that the nano3G sends is always</p>
<pre><code>e000df99160051673c01270000820000001710000100</code></pre>
<p>which we echo back with 'e4' written over the start.<br />This looks nonstandard / ip.access specific.<br />However, when looking at the sysmocell5000, we also get an 'e0' in the first RTP frame payload:</p>
<pre><code>e000dcf9...</code></pre>
<p>This is a completely different femto cell stack sending the same weird e0 byte,<br />so there seems to be something about this e0 that we don't know yet.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=29722017-02-02T15:09:29Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The solution to the nano3G RTP payload is that IuCS actually uses IuUP, UP encapsulated in RTP.<br />See 3GPP TS 25.414, and 25.415 6.6.2.</p>
<p>With the SysmoCell5000, echoing its own Initialization back to itself results in an ACK<br />being sent, which we can also echo back to itself, so mere echoing works there.</p>
<p>The nano3G seems to not reply with an ACK when it receives an IuUP Initialization frame.<br />Thus it is not possible to merely echo its own RTP packets back to itself; instead, the<br />first RTP frame received from the nano3G (that is an IuUP Initialization) can be changed<br />to an ACK Initialization by writing 0xe4 to the first payload byte. Sending this back to<br />the nano3G then results in successful RAB Assignment.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=30872017-02-20T13:47:54Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Still missing/untested for 3G voice is forwarding RTP streams between several cells and/or a 3rd party media gateway.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=30902017-02-20T14:00:33Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>Actually, also missing is to have a ring tone while dialling.</p>
<p>We're also currently echoing RTP back during call establishment, switching from echo to<br />forward once both legs of a call are established. It works, but maybe that's not the<br />proper way to do it. But changing this is low priority, might depend on a media gw.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=31302017-02-24T14:48:04Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>On the sysmocom/iu branch, OsmoCSCN has been renamed to OsmoMSC.<br />I'm also sweeping osmocom.org to apply the rename.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=32042017-03-02T17:42:01Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>While rebasing onto VLR, I see that we haven't yet implemented sending cipher mode cmd over Iu.<br />Will be swift to add with the VLR code in place, and it does work on 2G, just noting it.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=32212017-03-04T04:16:29Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>While rebasing onto VLR, I see that we haven't yet implemented sending cipher mode cmd over Iu.</p>
</blockquote>
<p>We do SecurityModeControl; need to clarify whether that is "the same" as Ciphering or in addition.<br />I knew it once but forgot...</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=39612017-05-15T13:56:17Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Stalled</i></li><li><strong>Assignee</strong> changed from <i>neels</i> to <i>118</i></li></ul><p>neels wrote:</p>
<blockquote>
<p>We do SecurityModeControl; need to clarify whether that is "the same" as Ciphering or in addition.</p>
</blockquote>
<p>Yes, that's sufficient.</p>
<p>Generally, we still need to resolve directing RTP between multiple hNodeBs, which will also relate to recent AoIP developments. We are focusing on AoIP now; I'm not working on 3G at present, we'll mark back to in-progress when someone is actually working on it.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=40462017-05-24T12:27:19Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-3 priority-high3 closed" href="/issues/2265">Bug #2265</a>: OsmoMSC must DLCX after a voice call is done</i> added</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=40482017-05-24T12:27:34Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-5 priority-3 priority-high3 closed" href="/issues/2279">Bug #2279</a>: osmo-mgcp-gw: Fix: cleanup of transaction IDs aka port numbers to be used by the MGCP gw</i> added</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=40632017-05-24T13:39:23Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/1845">Feature #1845</a>: Full BSC/MSC split in NITB/MSC</i> added</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=40662017-05-24T13:39:27Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> deleted (<i><a class="issue tracker-2 status-6 priority-2 priority-default closed" href="/issues/1594">Feature #1594</a>: Split of BSC part from CoreNITB part</i>)</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=40712017-05-24T13:41:43Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-3 priority-2 priority-default closed parent" href="/issues/2260">Feature #2260</a>: "next generation" osmo-bsc_mgcp</i> added</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=40762017-05-24T13:57:03Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>Stalled</i> to <i>In Progress</i></li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=40782017-05-24T13:58:25Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-2 priority-default closed" href="/issues/2264">Feature #2264</a>: make sure osmo-hnbgw re-connects dynamically</i> added</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=40852017-05-24T14:10:00Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-3 priority-high3 closed" href="/issues/2281">Feature #2281</a>: allow multiple MGCP-GW per MSC</i> added</li></ul> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=41622017-05-30T12:57:41Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>70</i></li></ul><p>(for some reason the % Done value was reset to 0)</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=45742017-07-17T10:54:15Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>loosely related: dexter has fixed the MNCC connector functionality on the 3G+AoIP branch, hence possibly allowing to route calls between 3G and SIP. Needs to be tested, obviously. One question there is whether/which external PBX support IuUP, the special within-RTP encapsulation used in 3G.</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=56402017-10-09T14:56:45Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>% Done</strong> changed from <i>70</i> to <i>100</i></li></ul><p>We have open issues with 3G voice about IuUP and the nano3G needing the IuUP Initialization Ack message and routing of calls between 2G and 3G,<br />but it makes decreasing sense to keep this issue open.</p>
<p>Let's see IuCS as initially implemented, especially since it now is merged on osmo-msc master, available and working.</p>
<p>For ongoing development, see <a class="issue tracker-2 status-3 priority-2 priority-default closed behind-schedule" title="Feature: Implement way how to handle IuUP on RTP endpoints (Resolved)" href="https://projects.osmocom.org/issues/1937">#1937</a>, <a class="issue tracker-2 status-3 priority-2 priority-default closed behind-schedule" title="Feature: remove nano3G IuUP "Initialization ACK" hack when IuUP proxy is in place (Resolved)" href="https://projects.osmocom.org/issues/2459">#2459</a>, <a class="external" href="https://osmocom.org/projects/osmomsc">https://osmocom.org/projects/osmomsc</a> , <a class="external" href="https://osmocom.org/projects/osmo-mgw">https://osmocom.org/projects/osmo-mgw</a> ...</p> OsmoNITB - Feature #1712: 3G Voicehttps://projects.osmocom.org/issues/1712?journal_id=56912017-10-11T02:48:58Zlaforge
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li></ul>