We've run into an issue again, where a provider won't accept re-INVITEs for session refresh where the SDP version counter hasn't been incremented. Has there been any work on this or should I open an issue at github to make this issue more visible?

On Fri, 4 May 2018 at 17:51, Richard Fuchs <rfuchs(a)sipwise.com> wrote: > On 04/11/2018 09:28 AM, George Diamantopoulos wrote: > > Hello all, > > > > I have the following issue (I think) with RTP engine. An INVITE comes > > in, and rtpengine will rewrite the SDP accordingly, as configured in > > kamailio.cfg. After some time a reINVITE is sent out in the opposite > > direction, for session refresh purposes. As I use rtcp-mux-offer in > > kamailio.cfg for this direction, RTPengine will inject the rtcp-mux > > parameter, and this reINVITE is forwarded to the UAC that sent the > > original INVITE. > > > > However, the SDP in the reINVITE is exactly the same as the SDP in the > > 200 OK to the original INVITE, with the exception of the rtcp-mux > > parameter. Since the SDP offered from the same end has changed, > > shouldn't session version be incremented as well? > > > > Does this sound like something that should be reported as a bug to > > rtpengine? Or am I missing something here? > > Technically of course you're correct in that the version counter should > be incremented if the SDP changed. Currently rtpengine always leaves the > o= line unchanged, so there can be a discrepancy here in certain cases. > This should probably be fixed, but this is also the first time I've > heard of this actually causing an issue.