[SR-Users] RTPengine: shouldn't SDP <sess-version> be incremented when SDP is updated in-dialog?

[Henning Westerholt]

Am Montag, 19. November 2018, 11:40:53 CET schrieb George Diamantopoulos:
> 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?

Hello George,

is this an issue in the kamailio module or in the rtpengine daemon? If the 
former: I did a quick review of the commits for the rtpengine module, did not 
found a fix for this topic. It would be good to open a github issue for this.

If its an issue in the rtpengine daemon, please open an issue in the 
respective github project: https://github.com/sipwise/rtpengine

Best regards,

Henning

 
> On Fri, 4 May 2018 at 17:51, Richard Fuchs <rfuchs at 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.


-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services
Kamailio security assessment - https://skalatan.de/de/assessment