For IuUP -> AMR, we log a message like
Convert IuUP -> AMR OA:...
Do the same for the direction AMR -> IuUP.
Related: SYS#5092
Change-Id: I525685a7dedb6d5d1deecbd026844cbe23193fac
The Osmux implementation in libosmo-netif expects to work with RTP AMR
in octet-aligned mode. Therefore, if the peer connection received RTP
AMR in bandwidth-efficient mode, we need to convert it to octet-aligned
before feeding the packets to the osmux layer.
Related: SYS#6161
Change-Id: Ifeec44241079f7a31da12745c92bfdc4fb222f3a
The new prefix now matches other related functions acting on an osmux
connection.
Pass the msgb to it so simplify new msgb copy.
Change-Id: I8c0121485d0c96f70fe8bcbdb150793d428183ff
The previous name is misleading since the function is not really sending
stuff over a socket, but rather handling/dispatching the incoming
message internally (and finally later it may be sent over a socket under
some conditions).
Change-Id: Idaf791997b8438a4aede50f614afa0d55ad41faa
First validate the origin of the message, then later the content
of the message and finally execute whatever triggers are necessary.
This way contents from unknown senders are not even parsed or acted
upon, avoiding useless potential harm.
Change-Id: I011a6d7d705768c32a35cec5cd7169725a21a670
The previous naming was quite confusing, since the function is not
really checking whether a conversion is needed, but rather whether the
codec has the AMR RTP mode defined explicitly and hence forced.
The previous naming didn't harm because the amr_oa_bwe_convert also
supports the conversion path OA<->OA and BE<->BE.
Hence nowadays the amr_oa_bwe_convert() function is called always if the
dst conn has its codec with AMR RTP mode explicitly set, no matter if
the src and dst conn have the same mode.
Related: SYS#6161
Change-Id: I8dce3038ebccf5e1e37e2908070a67d66693a96f
Enhance the existing log message
Convert IuUP -> AMR:...
to
Convert IuUP -> AMR OA:...
(or BE) to show wether emitting Octet-Aligned or Bandwidth-Efficient.
Related: SYS#5092
Change-Id: I3672d01d2879ae8820176a46454f26a4f5f584de
When converting IuUP to AMR/RTP, bridge_iuup_to_rtp_peer() sets the AMR
side's payload type number and then calls mgcp_send(). In mgcp_send(),
do not attempt to patch the payload type number a second time.
In mgcp_send(), skip patching payload type numbers if the source side is
IuUP. This matches exactly the case of converting IuUP to AMR/RTP.
There already is a check for IuUP, but for the wrong side. Drop that one
and explain in a comment why.
Move the comment about transcoding into the failure branch, where it is
relevant and doesn't clutter the new explanation of payload type
patching conditions.
Related: OS#5720
Related: SYS#5092
Change-Id: I7c722cd959f76bd104ae4941d182c77e5c025867
Fix the reversed logic when composing IuUP.FQC:
AMR.Q == 1 means the frame is good.
Without this fix, all frames on IuUP are marked as bad, and no voice is
heard on the IuUP side.
Related: SYS#5092
Change-Id: I29878dd27af9ba0c9e600324c528b22940cdcc30
When translating AMR to IuUP, when AMR data arrives before the IuUP side
has negotiated an IuUP Initialization, do not crash osmo-mgw, but return
failure and drop the AMR packet.
As soon as IuUP Initialization occured and RFCIs are defined, the AMR
starts to pass through to the IuUP side.
Related: SYS#5092
Change-Id: Id9efb7e523d8d9af988e4bf4f5e925839204f934
* Move all of them to an anonymous "osmux" substruct to have them all
together.
* Rename some fields to clarify its meanings, similar to what
was already done in osmo-bts.
* Move the port VTY config next to the ip address ones.
Change-Id: Icc1c1ce3ab3a8beb941cda7c112485a0db882a90
It's basically the same code path (one function calls the other), but it
makes a lot more sense to have it in the init function itself.
Change-Id: I63d7dfff451870f708f7cb710d66f4ec786c27d7
Parameters passed to several functions are rearrange to make code
simplier to follow, as well as dependencies between the different
functions. As a result, some parameters can be marked as const while
doing the change.
Change-Id: Idebd4a66630c16548f557632a54d6b7e1b3906fd
It's checked in all code paths being called, which makes sense since
it's impossible to send anything if the remote address is not set. Let's
check it once in a unique to simplify the code.
Change-Id: I224dbfeda17c364b85166268e2ac1e019a87edb6
A new osmux bind-ip-v6 VTY command is added, similar to what's already
available for RTP. This way the user can decide whether to support IPv4,
IPv6 or both types of IP versions.
Both IP sockets are by default disabled, and must be explicitly enabled
by setting the bind-ip in the VTY configuration.
Change-Id: I446cd7da217e9f4a74995d7784ae55dcc60a29b7
Since recently the port is guaranteed to be placed at
CRCX/MDCX in the sockaddr, hence we can check it using the API instead
of checking manually only for the address part.
In osmux_send_dummy() we actually fix a bug where an in_addr was being
compared against a struct sockaddr.
Change-Id: I736e7f4c51e577d8eb0b96bc776f984f928b6d27
Let's use the port part of the struct mgcp_rtp_end->addr field instead
of keeping it separate. This makes it easier passing around and
using/checking the RTP remote address + port, and avoids confusion
having to check stuff outside of the address, with its port part
potentially unset.
Change-Id: I294eb5d85fae79bf62d36eb9e818426e187d442c
A commit refactored this code around one year ago, which broke osmux
detection of dummy messages. This commit partially reverts the earlier
commit and rearranges the existing code to make it more robust.
Fixes: b3d14eb552
Change-Id: Iedf085932c45af5d13e04e56a4cd1082de81d869
There's no need to separate between BSS and CN side nowadays, the
different types are used nowehere. This separation dates from
osmo-bsc-nat code days.
Change-Id: I65effeddf033eb1955553e8d659c593b4e67f7bc
Documentation of rtp_bridge_cb was outdated, and caused confusion when
adding initial osmux support. Let's clear all the mess.
Change-Id: I42d1f2e2919eae3b1555ca4929e571855960792e
This way we have no more access to internal osmux structures.
Moreover, we already have similar information in our rate_ctrs, so
there's no need to print those there.
Change-Id: I853e118f843070ea29b19e1b0fe56b52f267437a
Receiving an unknown CID (for which we don't have an active conn) is
totally expected at the end of the call, were some messages from the
peer may be send for a while, specially if latency is high.
If this occurs, we simply drop that batch and keep decoding the osmux
message in order to keep delivering content to other circuits.
Related: SYS#5987
Change-Id: I315949853bdcc07bef15d2e8579029cc72c427cf
This is actually quite common, since our peer may be sending some osmux
packets to us a while after we have closed the conn on our side,
specially if latency is high in the network (eg satellite links).
Related: SYS#5987
Change-Id: Idffd91b68d1f98ac906d78e7fbc0e6eaa1962f9e
Let's not delay allocation of rate counters until the osmux conn is
fully enabled, since we may want to count stuff before that point in
time.
Fixes crash accessing null conn->osmux.ctrg in
MGCP_Test.TC_two_crcx_and_rtp_osmux_bidir.
Change-Id: Ic31d3567f4d24e628f8983d8362e5c7c2f66ec02