baresip: audio call is automatically modified to audio-video call after 200 OK is received

Using latest main, I noticed the following with my baresip+ app:

baresip+ sends audio only INVITE to Linux baresip
after receiving audio only 200 OK, I get to log:

07-31 10:58:47.924 21275 21347 D Baresip+ Lib: call: got SDP answer (472 bytes)
07-31 10:58:47.945 21275 21346 D Baresip+ Lib: ua event (CALL_REMOTE_SDP) answer
07-31 10:58:47.946 21275 21346 D Baresip+ Lib: video RTP/AVP
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:   local formats:
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:      96 VP9/90000/1 () *
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:      97 VP8/90000/1 () *
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:      98 H264/90000/1 () *
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:      99 H264/90000/1 () *
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:      34 H263/90000/1 () *
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     100 H265/90000/1 (profile-id=1) *
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     101 AV1/90000/1 () *
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:   remote formats:
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:   local attributes:
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     rtcp-rsize
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     ssrc='132011099 cname:sip:bar@test.tutpro.com'
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     mid='1'
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     framerate='15.00'
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     rtcp-fb='* nack pli'
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     content='main'
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:     label='2'
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:   remote attributes:
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:   local direction:  inactive
07-31 10:58:47.946 21275 21346 D Baresip+ Lib:   remote direction: sendrecv
07-31 10:58:47.946 21275 21346 D Baresip+ Lib: 
07-31 10:58:47.946 21275 21346 D Baresip+ Lib: local media dir 0
07-31 10:58:47.946 21275 21346 D Baresip+ Lib: remote media dir 3

baresip+ sends ACK
after that baresip+ automatically modifies the call by sending audio/video re-INVITE

In my opinion that should NOT happen. User must have control if video is enabled for the call. This did not happen earlier, but I don’t know before which commit. Please revert back to earlier behavior.

About this issue

Original URL
State: closed
Created 2 years ago
Comments: 31 (2 by maintainers)

Commits related to this issue

call: remember media dir for established state Fixes issue #2042 - The function call_set_media_direction() should remember the audio/video dir for the established state - Rename call_set_media_ansd... — committed to cspiel1/baresip by cspiel1 2 years ago
call: remember media dir for established state (#2046) Fixes issue #2042 - The function call_set_media_direction() should remember the audio/video dir for the established state - Rename call_set... — committed to baresip/baresip by cspiel1 2 years ago

Most upvoted comments

Thank you very much. I tested both calling and answering and both worked with these API calls:

Call (vdir = Api.SDP_INACTIVE or Api.SDP_SENDRECV):

Api.ua_call_alloc(ua.uap, 0L, Api.VIDMODE_ON)
Api.call_set_media_direction(callp, Api.SDP_SENDRECV, vdir)
Api.call_connect(callp, uri)

Answer (vdir = Api.SDP_RECVONLY or Api.SDP_SENDRECV):

Api.call_set_media_direction(callp, Api.SDP_SENDRECV, vdir)
Api.ua_answer(uap, callp, Api.VIDMODE_ON)

juha-h on Aug 3, 2022

API function ua_connect_dir has this code after ua_call_alloc:

if (adir != SDP_SENDRECV || vdir != SDP_SENDRECV) {
		err  = call_set_media_ansdir(call, adir, vdir);
		err |= call_set_media_direction(call, adir, vdir);
		if (err) {
			mem_deref(call);
			goto out;
		}
	}

As I explained, I need to call ua_call_alloc in order to get callp before calling call_connect. Thus I cannot use ua_connect_dir and need access to call_set_media_direction or some other function that has the same effect.

juha-h on Aug 2, 2022

Thanks for the help. I’m currently on the road, but will try your suggestions later today.

juha-h on Aug 2, 2022

after that baresip+ automatically modifies the call by sending audio/video re-INVITE

In my opinion that should NOT happen. User must have control if video is enabled for the call. This did not happen earlier, but I don’t know before which commit. Please revert back to earlier behavior.

Right! But I suggest to find and solve the problem and not revert anything.

cspiel1 on Aug 2, 2022

Let me see! I will check this.

cspiel1 on Aug 2, 2022