Answering re-invite sends a modified SDP file without incrementing version

[zecke]

In Asterisk we see the following issue: https://issues.asterisk.org/jira/browse/ASTERISK-28452. It seems that when the remote answer is processed the active_sdp might not be the same as the one offered. The next time it is used (e.g. in answering a re-INVITE) it will be sent without having increased the version number.

How should this work and what role does asterisk have? A work-around seems to increment the version number on active after successfully processing the answer.

pjproject/pjmedia/src/pjmedia/sdp_neg.c

Line 1564 in 3e8211d

status = process_answer(pool, neg->neg_local_sdp, neg->neg_remote_sdp,

[silentindark]

Hello, @sauwming . Could you please help with this topic?

[sauwming]

In the issue page, I believe Ivan has explained it well. Since app/user modifies the local SDP, I think it should be okay to also increase the version. Or is there any reason not to?

Note that I tested the scenario here with pjsua app and without the SDP modification, everything seems to work correctly.
Attached is the sipp scenario I used for testing:
uac-reinv-no-sdp.xml.txt

[jcolp]

There are actually two cases that I'm aware of. The case mentioned by Ivan is certainly one under the control of Asterisk. There is a second one, however:

In a scenario where PJSIP sends an initial INVITE with a set of codecs (ulaw and alaw) and the remote side answers with a single codec (ulaw) the SDP negotiator will change the active local SDP to include only that single codec (ulaw). This is done without incrementing the session version number.

If a user of PJSIP INVITE session does not implement the "on_create_offer" callback then when a re-INVITE without SDP is received the active local SDP is used, without the session version number incremented.

This doesn't impact pjsua as it appears to implement the on_create_offer callback which produces the SDP instead of using the active local SDP. I'm also implementing this callback in Asterisk which should fix both Ivan's case as well as the scenario I've just described.

It does feel as though there is a bug though if the on_create_offer callback is not implemented. Perhaps in INVITE session if it uses the active local SDP in that case it should increment the session version number.

[sauwming]

Other than the patch in #2646, let us know if there's anything else that needs to be fixed (or changed) on PJSIP's side in relation to this issue.

[jcolp]

I think you're good! That patch should do it, and if I get any more scenarios from users where things still aren't right I'll be sure to bring it up if applicable on the PJSIP side. So far I haven't had any comments/testing/feedback on the patch I've done Asterisk side.