This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi again, Attached to this mail you can find a more practical example of what I believe is the correct flow of primitives in a real-world location updating procedure between a SGSN (or MSC) and the HLR. As you can see, there are two linked invocations/transactions: 1) the actual location updating request (SGSN/MSC -> HLR) 2) the 'insert subscriber data' transaction that is triggered (HLR -> SGSN) 3) the complation of the location updating request after the insert subscriber data has been completed. It's actually quite "impressive" to see how much needs to happen for such a relatively simple task. The MAP-DELIMITER.ind is generated locally by the MAP-provider to the map user to indicate that it has finished sending all primitives for one incoming TCAP message/packet/pdu. It is used as a means of synchronization, to which the MAP-User then typically responds with a MAP-DELIMITER.req which in turn triggers the transmission of all queued primitives in a response message. Regards, Harald -- - Harald Welte <laforge at gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- A non-text attachment was scrubbed... Name: map_loc_upd.ps.gz Type: application/octet-stream Size: 11793 bytes Desc: not available URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20100718/43b63359/attachment.obj>