LCLS and osmo-sip-connector

historical

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.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)