Project

General

Profile

Actions

Bug #2322

closed

Make osmo-msc work with external mncc

Added by dexter almost 7 years ago. Updated over 4 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
06/12/2017
Due date:
% Done:

100%

Resolution:
Spec Reference:

Description

In its current state, osmo-msc does not work with the external mncc. This needs to be fixed.


Files

1499339643.tar.gz 1499339643.tar.gz 19.8 KB dexter, 07/06/2017 11:17 AM
Actions #1

Updated by dexter over 6 years ago

Tested with LCR (placed call to 21000). The call dies early. There is no activity seen on the LCR log, nor on the asterisk log. See attached traces: 1499339643.tar.gz

I suggest to try it with 3G in order to see if the problem is also present there.

Actions #2

Updated by neels over 6 years ago

I am personally not familiar with external call routing at all, I even just hope I used the term 'PBX' correctly. Correct me if I'm wrong...

With our MGCPGW this cannot work, because our code only ever connects our MGW back to itself.
We need to notice per call leg whether it comes from an external PBX and instruct the MGW to forward RTP there instead of to itself.
Alternatively the BTS could send the RTP directly to the external PBX instead of to our MGW.

Directly from BTS to PBX would be more optimal in the sense of CPU load and network latency, while having a guaranteed MGW hop would be more modular, allowing to have "completely" separate networks. Ultimately both ways could be nice to have in a configurable way? First focus on one of them though, whichever is easier.

Actions #3

Updated by neels over 6 years ago

dexter, please split this up in two separate issues: the issue description lists two completely orthogonal items. This would rather be two separate issues, one for MNCC and one for separate IP addresses.

In general, take care that you create issues for one specific task, with one specific summary text. "AoIP related tests" could be anything, anyone reading this in the list of issues would have to open the issue to know what is going on.

"more to be collected" is misplaced, each new item we collect in the future would become a new separate issue.

It is ok to have one parent issue with several subtasks, as long as the parent issue combines issues that are related or depend on each other. However, every time I tried that, it got cumbersome: placing other issue relations (like "Related to" or "Blocked by") becomes non-trivial and may be refused by redmine to avoid circular relations. And it is not always apparent in the UI that an issue is a child of another one. I've decided for myself to rather avoid parent tasks in the future, preferring the "Related" linking.

Actions #4

Updated by neels over 6 years ago

re MGCP with 3G, another question is whether the PBX understands IuUP, which is the 3G voice protocol encapsulated inside the RTP.

Actions #5

Updated by dexter over 6 years ago

  • Subject changed from AoIP related tests to Make osmo-msc work with external mncc
Actions #6

Updated by dexter over 6 years ago

  • Description updated (diff)
Actions #7

Updated by laforge over 6 years ago

neels wrote:

re MGCP with 3G, another question is whether the PBX understands IuUP, which is the 3G voice protocol encapsulated inside the RTP.

I think this will be resolved once we have a real osmo-mgw co-located with the MSC, which can then translate from IuUP to "native" AMR/AMR-WP in RTP. So I think it is out of scope for this ticket.

Actions #8

Updated by dexter over 6 years ago

  • % Done changed from 0 to 90

The problem is almost resolved. I have tested it with osmo-sip-connecter/asterisk. Seems to work fine now. The only thing I am not sure with is the codec negotiation (bearer cap). We will have to touch this part once more.

neels Does it still work for 3G?

Actions #9

Updated by dexter over 6 years ago

  • Status changed from In Progress to Stalled
Actions #10

Updated by dexter over 6 years ago

Note: This will move on as soon as we integrated the new osmo-mgw into osmo-msc.

Actions #11

Updated by dexter over 6 years ago

We are now almost done with the osmo-mgw integration in osmo-msc. So this test should be done soon. I have my asterisk setup up and running again, so it should work with my old osmo-sip-connector configs and external mncc.

Actions #12

Updated by dexter over 6 years ago

  • Status changed from Stalled to In Progress

I have tested osmo-msc with external MNCC (Asterisk) and after fixing a problem in the FSM it now works. However, I expect that there are still problem on the IuCS side.

Actions #13

Updated by dexter about 6 years ago

I had a look at the IuCS side last week. There is a problem with a response not parsed. I expect the external MNCC to work once this is solved.

Actions #14

Updated by dexter about 6 years ago

The problem with IuCS is now fixed and from what I can see the signalling looks ok with external MNCC. However, the external entity does not understand IuUP, so we need to fix this inside the MGW now to make it work.

Actions #15

Updated by dexter almost 6 years ago

Note: Did a test with external MNCC and the split branches last week. It still works, however the test was on 2g/FR only. I did not re-test on 3g

Actions #16

Updated by dexter almost 6 years ago

(Note: It has been reported that external MNCC is broken for LCR, but when I understand the isse there right, the breakage is due to wrong assumptions on the LCR side)

Actions #17

Updated by dexter almost 6 years ago

  • Status changed from In Progress to Stalled
Actions #18

Updated by dexter over 5 years ago

(Re-Tested recently on 2G, to see how DTMF behaves #2777, still works!)

Actions #19

Updated by laforge over 5 years ago

  • Priority changed from Normal to High
Actions #20

Updated by keith over 4 years ago

dexter wrote:

(Note: It has been reported that external MNCC is broken for LCR, but when I understand the isse there right, the breakage is due to wrong assumptions on the LCR side)

To clarify this [and I think the title and description of the ticket could be updated, or the entire ticket could be closed as superceded by other tickets]

LCR is expecting lchan info in the MNCC message. without this it fails.

The osmo-sip-connector is earmarked to become the defacto MNCC-SIP connector.
I don't believe there are any plans to make LCR work with osmo-msc

Actions #21

Updated by laforge over 4 years ago

On Mon, Aug 05, 2019 at 02:32:19PM +0000, keith [REDMINE] wrote:

LCR is expecting lchan info in the MNCC message. without this it fails.

Then LCR should be fixed, IMHO. It's simply wrong to have such a low-level detail
about the radio interface connection exposed on the core network interface to LCR.

I don't believe there are any plans to make LCR work with osmo-msc

In general we should maintain compatibility as far as possible. I guess it
needs somebody to actually look and understand why lcr is using this value,
and what kind of alternatives there are.

The point of having an "interface" is interoperability...

Actions #22

Updated by dexter over 4 years ago

  • Status changed from Stalled to Resolved
  • % Done changed from 90 to 100

This Ticket is from the time when we have introduced the A-Interface. MNCC had to be touched to make it work again with external MNCC. It still works, I am using external MNCC at the moment with osmo-sip-connector. However, there are some limitations regarding the codec negotiation but those should be addressed by other tickets.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)