OsmoNITB - Bug #1604: Easier / more direct SIP integration
osmo-sip-connector: Implement codec selection
We need to select codecs.. There were multiple mails on the OpenBSC list. For GSM MO call we need to check the bearer calls and the availability of channels and then can offer different codecs. The FR vs. HR decision needs to be done early but then codec can be changed.
The MNCC protocol needs to change in many still to be defined ways. This includes:
- NITB needs to inform which TCH/F.. TCH/H are available
- RTP_CREATE/RTP_CONNECT needs to include AMR mode-sets
- Need to test switching codec
- BTS needs to support Payload2 to allow asymentric PayloadType for the same codec!
#7 Updated by laforge over 1 year ago
- respect the codec capabilities of all elements, i.e.
- the external SIP world (as in the SDP)
- the MS (bearer capabilities)
- the BTS+BSC (codec lists in BSSMAP ASSIGNMENT related messages)
- prefer a non-transcoding situation to any that involves transcoding
- if transcoding is required, it should happen at the bsc-located OsmoMGW
- INVITE with SDP is received
- INVITE is translated to MNCC_SETUP_REQ
- if the SDP included any GSM related codecs (FR/HR/EFR/AMR), then those codecs should be translated to the MNCC bearer capability field. Otherwise, MNCC bearer capability is omitted (equals any codec/bearer)
- bearer capabilities should indicate a preference for those (in the same order as the SDP, as it also is ordered by preference). All other codecs shall be listed last, i.e. with lower preference
- OsmoMSC triggers paging towards BSC/BTS/...
- OsmoMSC sends the CC SETUP to the MT, including CC bearer capabilities translated from the MNCC bearer capabilities
- the MT MS responds, possibly with negotiated bearer capabilities, based on its own capabilities
- OsmoMSC at some point sends a BSSMAP ASSIGNMENT CMD listing the negotiated codecs
- OsmoBSC responds with a BSSMAP ASSIGNMENT COMPLETE, indicating the exact channel type + codec that was chosen (based on available chanels, the BTS model, local policy, ...)
- the MT MS responds at some point with a CONNECT (when the user picks up)
All in all, I think the ladder diagram should look like this:
#11 Updated by laforge over 1 year ago
After working on this for another two days, I have identified the following problems:
The question is what is the operator policy / optimzation target here? It could be
- perform as little transcoding as possible. This would possibly mean using more FR (TCH/F) than AMR/HR (TCH/H) assuming that the SIP peer supports FR natively but not AMR
- use radio resources as efficiently as possible. In this case we'd prefer AMR/HR over anything else and would then end up transcoding potentially every call if the SIP peer doesn't support AMR.
- case a (avoid transcoding) is useful if the machine running OsmoMGW is cpu constrained (like a deeply embedded system)
- case b (optimize radio resources) makes sense in all cases where sufficient transcoding capacity is available
MO call: SDP from SIP side will arrive late ("200 OK" to INVITE)¶
- in classic SIP, the offer of codecs is made in INVITE, and the response only in "200 OK"
- this means for MO we couldn't select the least common denominator between GSM and SIP side (to avoid transcoding) until the SIP UA has already picked up the phone.
- RFC3262 offers the option to send the response SDP in "Reliable 18x" responses. The question is: Who supports this? If support is wide-spread this would be a solution. We would then request reliable 18x responses and wait with the BSSMAP Assignment until we have the "180 Ringing" from the SIP side, at which point we can try to assign a channel with the codec supported by the SIP side to avoid transcoding.
osmo-mgw / libosmo-mgcp[-client] shortcomings¶
libosmo-mgcp_clientdoesn't seem capable of properly encoding SDP with multiple codec options (rtpmap) :( #3115
libosmo-mgcpseems capable of properly parsing SDP with many codec options (rtpmap) but then only passes up to two from the parser upwards :( - see
complete MNCC breakage in OsmoMSC¶
osmo-msc contains funny bits of code like hard-coding the RTP payload type in the MNCC_RTP_CREATE to "0", rather than using any of the actual codecs, see e.g.
»·······/* FIXME: This has to be set to some meaningful value, »······· * before the MSC-Split, this value was pulled from »······· * lchan->abis_ip.rtp_payload */ »·······uint32_t payload_type = 0;
This is absolutely not acceptable and basically breaks functionality of MNCC beyond expectations. In my testing, osmo-sip-connector is never able to find a common codec between the SIP and GSM side, as the SIP side of course is right to accept any re-definition of a non-dynamic RTP payload type "0".
#13 Updated by laforge over 1 year ago
On Mon, Mar 26, 2018 at 03:48:21PM +0000, zecke [REDMINE] wrote:
A pre-selection could already be made at the time of paging? GSM 08.08 holds "Channel Needed" to indicate if a Full rate or Dual rate channel should be required.
OsmoBSC will to my knowledge ignore that, as we always use late assignment these days.
So it will use the "smallest available" channel to handle the signaling until the cal
goes into alerting state, when the BSSMAP assignment is used.
Supervisory Tones, indicating primarily ringing, engaged and unobtainable numbers, may be generated by
both the PLMN and PSTN
Except for ring tone, all tones indicating call progress to a Mobile Station user shall be generated in the
MS, on the basis of signals from the network where available, and are according to the standard defined
in this specification.
Tones sent to a caller to a mobile station will be generated in the network, generally local to the caller, and
will be to the standard of his local exchange, except for mobile to mobile calls, where the tones will be
generated in the calling MS. For mobile terminated calls, the ring tone will be generated in the called MSC
This means that if we are using a SIP UA connected to the GSM network, we should have it behave in a compatible way. That is to say, we should not send 180 Ringing when we are the "CALLED MSC", but rather we should send 183 with SDP and then start sending ring-back media.
For a SIP call terminating in our MSC we should be generating ring-back in the MSC and our SIP UA should be configured to expect this.