summaryrefslogtreecommitdiffstats
path: root/tests/vty/ok_indented_root.cfg
diff options
context:
space:
mode:
authorPau Espin Pedrol <pespin@sysmocom.de>2019-04-16 15:47:59 +0200
committerPau Espin Pedrol <pespin@sysmocom.de>2019-05-13 17:54:44 +0200
commit18506c850c3bbcbfa814e07dc02a17fdb5f7bb9a (patch)
treedc184100572bce10bf914f030f35f18387d8db7c /tests/vty/ok_indented_root.cfg
parent38176d297d63af994dcd2d96bdc0b93895db98dd (diff)
gsm0808: Introduce Osmocom extensions to announce Osmux support
IE GSM0808_IE_OSMO_OSMUX_SUPPORT (T, 1 byte) is sent in AoIP appended to BSSMAP RESET in order to announce the peer that its MGW supports handling Osmux streams upon call set up. IE GSM0808_IE_OSMO_OSMUX_CID (TV, T 1 byte & V 1 byte) is sent in AoIP during call set up: * MSC->BSC Assignment Request * BSC->MSC Assignemnt Complete The 1 byte value contains the local Osmux CID, aka the recvCID aka CID where the peer sending the Assign Req/Compl will look for Osmux frames on that call. Hence, the peer receiving this CID value must use it to send Osmux frames for that call. As a result, a given call leg BSC<->MSC can have one different Osmux CID per direction. For example: * MS => MGW_BSC ==CID 0==> MGW_MSC * MS <= MGW_BSC <=CID 1=== MGW_MSC This allows for setups with 256 call legs per BSC on scenarios where NAT is not a problem, where MSC can have a pool of 256 CID per MGW_BSC (or remote peer). Related: OS#2551 Change-Id: I28f83e2e32b9533c99e65ccc1562900ac2aec74e
Diffstat (limited to 'tests/vty/ok_indented_root.cfg')
0 files changed, 0 insertions, 0 deletions