Hi,
sharing a few thoughts for the osmodevcall tomorow.
I did a few tests today with a 2G and a 3G network, using current master
of everything plus:
* my osmo-mgw IuUP patch for osmo-mgw:
https://gerrit.osmocom.org/c/osmo-mgw/+/26823
* Philipp's osmo-hnbgw.git branch pmaier/mgw which makes osmo-hnbgw use
osmo-mgw to route calls
2G_MO <-> 2G_MT:
Fine, as usual.
3G_MO <-> 3G_MT:
Everything seems to be working fine here. MSC and HNBGW configure all
MGCP conns during CRCX with IuUP (audio codec "VND.3GPP.IUFP/16000").
When receiving that audio codec, osmo-mgw upgrades the conn to be of
type "IuUP" and handles packets/state accordingly. Then IuUP is used
everywhere and properly routed nano3g <-> MGW_hnbgw <-> MGW_msc <->
MGW_msc <-> MGW_hnbgw <-> nano3g. IuUP SMpSDU Init (ACK) are negotiated
between each peer.
2G <-> 3G:
The idea here is to have at least limited interoperability (no
transcoding, meaning 2g network needs to probably be configured to allow
only AMR, and only AMR modes supported by nano3g). osmo-mgw already
takes care of reframing the AMR payload between IuUP and RTP AMR-OA/BE.
To accomplish that, lots of stuff is working fine already (see test
https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/26860 passing). The only
main problem right now is that the CN-side endpoint connections of
osmo-mgw attached to osmo-msc are not properly configured (all others
look fine).
Right now, osmo-msc, when sees the call leg it is preparing is for a
UMTS subscription, as explained later, sends audio codec
"VND.3GPP.IUFP/16000" during CRCX on both conns in the endpoint
(RNC-side and CN-side). On the other leg (2G), MSC does the same but
using AMR audio codec. When both legs are ready, it connects the 2
CN-side connections of each leg (2g and 3g ones) together, in
call_leg_local_bridge(), using MDCX on both, and it actually properly
sets AMR codec on both, since in this case we want the 2 leg bridge
between 2G and 3G endpoints to be done in RTP+AMR.
However, osmo-mgw doesn't support "downgrading" an already
"upgraded"
RTP->IuUP conn back IuUP->RTP during MDCX, which means MGW currently
fails to process the packets because it expects to receive the other RTP
vs IuUP type. And it think it shouldn't support that. Instead, we should
[A] avoid probably avoid configuring any codec during CRCX on CN-side
connection, to avoid the upgrade RTP->IuUP of the connection. [B] Later,
during call_leg_local_bridge() when we know the codec for both, iif both
conns are from UMTS subscribers then send the codec
"VND.3GPP.IUFP/16000". [C] somo-mgw will then upgrade the conns
RTP->IuUP during MDCX.
[A] To implement this, it's probably a one line. See osmo-msc.git
d7955315646b9ba2942e4d5ae58c5d43763d9be6, we need to set
.codec_present=false there.
[B] This may already be done automatically. Otherwise we need to poke
around call_leg_local_bridge() code to do it.
[C] In my osmo-mgw patch, so far the RTP->IuUP upgrade is only done
during CRCX, but it should be easy to apply the upgrade during MDCX too.
I'm attaching a sample pcap file showing a call 2g<->3G of the tests I
did today. Filters used to export the file:
"sctp || rtp || rtcp|| mgcp || gsm_abis_rsl"
Diagram of the IuUP/RTP paths in the pcap:
------------------
[nano3g]
192.168.1.138:1036
------------------
||
|| (IuUP)
||
------------------
192.168.1.140:4002
[MGW_hnbgw]
192.168.1.140:4004
------------------
||
|| (IuUP)
||
------------------
127.0.0.2:9022
[MGW_msc, 3g leg]
127.0.0.2:9024
------------------
||
|| (RTP/AMR both dirs desired, currently: 1 dir RTP/AMR, 1 dir IUUP)
||
------------------
127.0.0.2:9028
[MGW_msc, 2g leg]
127.0.0.2:9026
------------------
||
|| (RTP/AMR)
||
------------------
192.168.30.1:4030
[MGW_bsc]
192.168.30.1:4028
------------------
||
|| (RTP/AMR)
||
------------------
192.168.30.1:16392
[BTS]
------------------
Kind regards,
Pau
--
- Pau Espin Pedrol <pespin(a)sysmocom.de>
http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte