If a message that has triggered the E-Routing-Error contains no
session related IEs, they will also be absent in the error message.
Change-Id: Iaf9d8e77c8734672cfd8a265b8cfdb3bc929a31b
The special 'all' keyword has been deprecated a long time ago
due to its ambiguity, and replaced by 'force-all'.
Change-Id: I759d96716e964d499c0724d481b2f3e5062fb052
Somehow despite all the warnings everywhere about keeping wiki + code
in sync, this didn't get updated :(
Change-Id: I37e4ea4e6ac8291a36761ecc1849f06847a69557
Several fixes and improvements to the documentation.
This documentation still doesn't contain infrmation about TRXDv1, it
will be added in a follow-up commit.
Change-Id: I36e6206b90435964842f9f1ebd982cdaf9777018
Message formats of the new messages look mostly the same (IMSI,
Message Class, Source Name, Destination Name, AN-APDU). That is, because
AN-APDU is storing results, error reasons etc. This can be seen clearly
in osmo-msc.git:
* src/libmsc/msc_a_remote.c:msc_a_remote_fsm_communicating()
* src/libmsc/msc_i_remote.c:msc_i_remote_fsm_ready()
The message squence charts in the E Procedures section are directly
based on Neels' interMSC_HO_GSUP_msgs.txt [1].
It seems that using AN-APDU made some other new IEs redundant: RR Cause,
BSSAP Cause, Session Management Cause had been added to GSUP for the MSC
handover, and are documented now, but they are currently not used in
osmo-msc.git. The new message OSMO_GSUP_MSGT_E_ABORT is not used either,
so I left a stub for it in the message format section.
I mentioned in the Source Name IE section, that source and destination
names are sent as nul-terminated strings. This is for legacy reasons,
Neels wrote a nice summary in the commit message of [2].
[1] https://osmocom.org/attachments/3720/interMSC_HO_GSUP_msgs.txt
[2] Change-Id: I9ca8c9eef104519ed1ea46e2fef46dcdc0d554eb (osmo-msc)
Related: OS#3774, OS#3619
Change-Id: I6b9f23d08cfe53c8b77f51c6afb900c2badc9e2c
Move the "IMEI" and "IMEI Check Result" IEs from the "Session
(transaction) management" chapter (which describes session IEs) to the
"Information Elements" chapter. Add a comment to prevent this mistake in
the future.
Related: OS#2541
Change-Id: I6fd66419350e018a763b8fac3daf567b339a2637
Change-Id: I9a0536f285f98f24fec4d7318f1923782ed2e18c
Related Change-Id: Ie0150756c33c1352bc4eb49421824542c711175c
Related Change-Id: I549b6c8840a1e86caac09e77fb8bc5042d939e62
Make this part of the specification, so we can simplify libosmocore
code by knowing that error message is (request message | 0x000001).
Related: I46d9f2327791978710e2f90b4d28a3761d723d8f (libosmocore)
Change-Id: Iec1b4ce4b7d8eb157406f006e1c4241e8fba2cd6
Most likely, this was a copy-paste error. SGSN is not involved
in Supplemeptary Services handling, they are pure CS data.
Moreover, HLR is not the only entity that can initiate both
Process Supplementary Service Error and Response messages,
there is also EUSE (External USSD handling Entity).
Change-Id: I46ad7311747f2b392244c49d3df1e152e6f1bfe3
Change hardcoded ../common paths, which will break when moving the
project specific manuals in other repositories, to ./common so they
use the dynamically created symlink that always points to the right
path.
(moving manuals to project repositories 8/19)
Related: OS#3385
Change-Id: Id984f5e85481f7877567ee6d21f7ca455d773ef1
We reference the port list appendix where all the ports used by various
Osmocom projects are listed and it's unlikely that pointing out the
osmo-nitb port would significantly help the reader, so just remove the
reference.
Change-Id: I354d50314ba248835191fa3da122032201618a0e
Surrounding with '@' didn't seem to yield the intended result, the
charactars appeared in the compiled document.
Change-Id: I66e7949fa4a6c2164bf9572a2beaf8ace169fa1c
Those graphs + message sequence charts are not yet used by any
of our manuals, but they should become used by the OsmoMSC user
manual once SGs interface support is added.
Related: OS#2583
Change-Id: Idfd3a66c18131b5458d183b8e66f62eaaab65991
Neels Hofmeyr
Pau Espin
Harald Welte
Daniel Willmann
Martin Hauke
Oliver Smith