I have encountered an issue where a UA is sending a re-invite to change the RTP port, but after the re-invite was sent, it still continues sending the last few packets of the first RTP stream. This causes RTPProxy to re-latch to the previous port and then ignore and discard all packets from the new port.
The following code in the _rtpp_stream_check_latch_override function from rtpp.stream.c seems to be where things are going wrong:
if (SEQ_DIST(pvt->latch_info.seq, packet->parsed->seq) > 536)
return (0);
After changing the above to the following, the issue is resolved:
This allows for up to 50 packets to be received from the previous stream after receiving an update command.
Is there perhaps a better way to fix this issue? Would this change introduce any harmful side effects you can think of?
I realise that the UA is actually at fault here and my change is a hack/workaround to deal with the faulty UA, but could there also be other situations where RTP packets may arrive late which would also result in the same issue? Maybe then it would be better to correctly handle this type of situation.
I have encountered an issue where a UA is sending a re-invite to change the RTP port, but after the re-invite was sent, it still continues sending the last few packets of the first RTP stream. This causes RTPProxy to re-latch to the previous port and then ignore and discard all packets from the new port.
The following code in the _rtpp_stream_check_latch_override function from rtpp.stream.c seems to be where things are going wrong:
After changing the above to the following, the issue is resolved:
This allows for up to 50 packets to be received from the previous stream after receiving an update command.
Is there perhaps a better way to fix this issue? Would this change introduce any harmful side effects you can think of?
I realise that the UA is actually at fault here and my change is a hack/workaround to deal with the faulty UA, but could there also be other situations where RTP packets may arrive late which would also result in the same issue? Maybe then it would be better to correctly handle this type of situation.