Project

General

Profile

Bug #2322

Make osmo-msc work with external mncc

Added by dexter 4 months ago. Updated 19 days ago.

Status:
Stalled
Priority:
Normal
Assignee:
Target version:
-
Start date:
06/12/2017
Due date:
% Done:

90%

Resolution:

Description

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

1499339643.tar.gz (19.8 KB) dexter, 07/06/2017 11:17 AM

History

#1 Updated by dexter 4 months 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.

#2 Updated by neels 4 months 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.

#3 Updated by neels 4 months 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.

#4 Updated by neels 4 months ago

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

#5 Updated by dexter 4 months ago

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

#6 Updated by dexter 4 months ago

  • Description updated (diff)

#7 Updated by laforge 3 months 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.

#8 Updated by dexter 3 months 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?

#9 Updated by dexter 3 months ago

  • Status changed from In Progress to Stalled

#10 Updated by dexter 19 days ago

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

Also available in: Atom PDF