sip icon indicating copy to clipboard operation
sip copied to clipboard

Templated Metadata

Open justin0mcateer opened this issue 1 year ago • 5 comments

The metadata that is included with a SIP participant can be defined in the configuration, but appears to be static. Would there be any interest in (or aversion to) allowing the metadata value to be templated by perhaps passing in the Sipgo Request object to a standard Go string template (https://pkg.go.dev/text/template)? The template would be provided in the configuration, if a static string is provided, it would work as it does today.

I imagine that different users/use cases will require different data from the SIP signaling and trying to send them all through LiveKit seems like a never ending problem. Allowing the user to grab whatever fields are relevant to them and pass them through the opaque 'metadata' field seems like a general solution that will allow flexibility for different users.

justin0mcateer avatar May 14 '24 16:05 justin0mcateer

What kind of metadata are you thinking about? We have plans to expose general SIP metadata (e.g. caller's number, called number, etc) in a new immutable metadata on LK Participant. Supporting templates seems like an overkill for now.

dennwc avatar May 14 '24 19:05 dennwc

There are a couple of headers on the Invite which will be important to us and in some cases information from the Invite body.

justin0mcateer avatar May 14 '24 20:05 justin0mcateer

Hmm, I'd rather not run the full template engine just to forward metadata, so maybe there's some alternative that could get the same result.

For example, we can have forward_sip_metadata, which will be an array of SIP headers that server will then attach to a Participant.

Maybe something similar will work for SDP payload? What kind of info you want from there? Forwarding full SDP is probably not a good idea, since it lists all the IPs and ports for the call.

dennwc avatar May 17 '24 15:05 dennwc

Actually, the data from the body is not in the SDP, but a multipart MIME body. The body can contain more than one payload and this is delimited using multipart MIME.

As crazy as that sounds it is part of several IETF standards and something we would be consuming from externally sourced SIP INVITEs.

justin0mcateer avatar Jun 18 '24 11:06 justin0mcateer

I see. That definitely makes proposed templating engine even more complicated :sweat_smile:

How about an alternative. After https://github.com/livekit/protocol/pull/733 is merged, SIP will be able to set KV metadata (attributes) on LK participants. And we can provide an integration point for you to parse INVITE reponse body and set these attributes.

You'll still have to either fork or import SIP into a separate binary that will add your parsing logic. But at least with a clear integration point it would be easier than maintaining a real fork.

What do you think?

dennwc avatar Jun 18 '24 13:06 dennwc