Trickle ICE Handling

[Huw Carpenter]

Hi,

What's the best way of handling trickle ICE in rtpengine, specifically when candidates are received after the main SDP block has already been passed to rtpengine?

I seem to have something working where I add the new candidate to the existing SDP block then effectively "re-play" the rtpengine command ("answer" in my case), including all flags and the full SDP block, but this duplication makes me think there might be a better way I haven't seen? I'm wondering if there's a command that just involves passing the new candidate and identifying information for the call and direction, such as call ID, from tag, to tag? I've looked through the docs and tried a few things with the NG client, but the when I tried to just provide the candidate with an offer or answer command, I see errors relating to not providing a fully-formed SDP block.

Thanks,
Huw

[Richard Fuchs]

Are you using an existing control module (e.g. Kamailio etc) or are you
managing the signalling to rtpengine directly yourself?

If doing it yourself, add `fragment` to the list of flags, and then just
signal an "offer" to rtpengine with the SDP fragment from the trickle
ICE update (and call ID and from-tag etc, as usual - no need for a to-tag).

Cheers

[Huw Carpenter]

Hi Richard,

Thanks for the information. 

I am managing the signaling to rptengine myself, so tried what you suggested, but got an error, "Error parsing SDP at offset 0: Missing '=' sign", when passing in the candidates for an answer, not sure if the syntax is correct though.

Attached are the logs, the call in question is 88506369...@192.168.0.50, my candidates are passed in on line 5207.

Thanks,

Huw

[Richard Fuchs]

On 03/07/2023 06.43, [EXT] 'Huw Carpenter' via rtpengine wrote:
> Hi Richard,
>
> Thanks for the information.
>
> I am managing the signaling to rptengine myself, so tried what you
> suggested, but got an error, "Error parsing SDP at offset 0: Missing
> '=' sign", when passing in the candidates for an answer, not sure if
> the syntax is correct though.
>
> Attached are the logs, the call in question
> is 88506369...@192.168.0.50, my candidates are passed in on line
> 5207.

First off you should probably use an "offer", with just the from-tag
corresponding to the client in question.

It's almost correct, but the candidates must be present in SDP format.
The contents are expected to reflect the payload of a SIP INFO message.
See https://datatracker.ietf.org/doc/html/rfc8840 for examples.

So at the very least you should present them as `a=candidate`, plus a
method of identifying which media stream they belong to (e.g. by having
matching `m=` lines, or an `a=mid` identifier).

Cheers

[Huw Carpenter]

Great, it's working now. Thanks Richard!