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/.
Keith keith at rhizomatica.orgHi all. I would like to implement some functionality that existed as a kind of happy accident?, in the osmocom-nitb That is - that media endpoints in INVITEs/200s and re-INVITEs from a SIP UA to osmo-sip-connector just ended up being transparently communicated to osmo-bts. This made it really easy to take the pbx out of the audio stream. I wanted to share where I am at with that. freeswitch even has a console command for this: "uuid_media" can switch the pbx in and out of the stream during the call. In the case of a MS to MS call on the same bts, we just connect the two osmo-bts media endpoints to each other. Freeswitch can schedule to playback message on calls and such like - for "your credit ran out" message for example - and it works pretty good. FS knows to put itself back into the stream with a re-INVITE with it's own IP in the SDP before playing the audio and invites itself back out of the stream as soon as playback is finished. I've been looking on and off, not that I've given it a huge amount of time, at how to replicate this with the BSC/MSC/MGW/SIP combination. First thing was to fix up the BSS messages and Global Call Reference generation. (TS 23.284) Given that Max had done most of this, that's pretty easy, although I got lost at one point down a rabbit hole of trying to figure out more than I needed to with the FSM and BSS messages, and that put me off working on it for a while. Anyway, https://gerrit.osmocom.org/c/osmo-msc/+/24236 exists and "works" - that is you can do LCLS with either mgw-loop or bts-loop configured on the BSC - but only for the internal mncc, obviously as the osmo-sip-connector still does not know what to do with the GCR (global call reference) I thought about various hackish things to do. (maintain a table of call-ids and their gcr on the sip conn and add an X-Osmo-CallID header to the SIP) but I've also been looking at the specs. TS 29.164 (section 6) says that the GCR should be encapsulated in a binary encoded ISUP payload, there are pointers in the spec to ITU Q.1912.5 (Section5 and thereabouts) So the ISUP messages should be added to SIP messages, requiring a multipart MIME attachment to the INVITE with the SDP and the ISUP. Also see RFC3204 What I don't know is how sip UEs will respond to these. I wonder will they decode them, I doubt it, some searching for SIP-I support in FreeSwitch confirms no support. So I'm thinking that I need to serialise the GCR and add it to an "X-" SIP header, so we at get it back on the B-leg. So yes, I need to just do this, but I got stalled a bit again with my lack on programming skills trying to learn how to serialise the GCR the "right" way. - but once I figure that out, then I can at least test what happens and see how the MSC and MGW behaves with the MNCC messages that result from SIP re-INVITES. Maybe that just works, but I don't think so, I think I will need to implement more BSS LCLS messages to actually change the LCLS states, not just update media endpoints. Sometimes I wonder here what should happen in the sip conn and what in the MSC. Anyway, It's been on my mind to write this up quickly to the ML just in case somebody has a "OH... better not do it like that" type comment.. Thanks k.