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?
Thanks!
Best regards, George Diamantopoulos
Has anyone run into or is concerned by this? Thanks!
On 11 April 2018 at 16:28, George Diamantopoulos georgediam@gmail.com 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?
Thanks!
Best regards, George Diamantopoulos
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.
Cheers
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?
Thanks! George
On Fri, 4 May 2018 at 17:51, Richard Fuchs rfuchs@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.
Cheers
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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.
-
George Diamantopoulos -
Henning Westerholt -
Richard Fuchs