Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

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.

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.

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.

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

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.

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?

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

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.

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.

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.

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.

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

(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)

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

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

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.