On Wed, May 26, 2021 at 08:26:04PM -0500, Keith wrote:
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.
yes, but it unfortunately also measn you cannot have separate, non routed networks between RAN and core network, which anyone with a reasonable interest in network security always wants to have, so you have to put some kind of RTP proxy like osmo-mgw co-located at the BSC level, as the BSC is the only element that has connectivity with the CN.
freeswitch even has a console command for this: "uuid_media" can switch the pbx in and out of the stream during the call. [...]
interesting to know, thanks.
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
oh my. Seriously? I just re-read the specs starting from 23.284 for LCLS and ideed you seem to be correct :(
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.
makes sense.
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.
isn't there already some kind of function to print it to a string?
- 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.
Which re-invites? I think it might be useful to create a ladder diagram of how you think this all works together.