[asterisk-dev] ASTERISK-29655 Fixing one-way video stream state (pjsip)

[Fridrich Maximilian]

Thank you for the quick response! I have made quite some progress towards
fixing ASTERISK-29655 by flipping the stream direction in two places in
res_pjsip_session.c: In new_invite() after create_local_sdp() is called and in
ast_sip_session_create_outgoing() the clone_stream direction is flipped. With
this change, one-way video works.

However, early media is not working yet with inband_progress=yes and
moh_passthrough=yes. Asterisk receives a 183 with audio:inactive and
video:recvonly, and forwards this 183 with audio:sendrecv and
video:inactive.

Reading the logs, both topologies are fine at first with both audios sendrecv,
one video recvonly and the other sendonly. It looks like the topology is being
messed up even before the 183 is received by Asterisk. In the logs we have

- 2nd call leg (callee): Queueing RINGING by chan_pjsip.c
- 2nd leg: Pending: <audio:sendrecv> <video:sendonly>, Active: null
- 1st leg (caller): Indicated Private Cause Code
- ...
- some lower level logs in res_rtp_asterisk, res_pjsip_sdp_rtp, channel,...
- ...
- 1st leg: Applied negotiated SDP media stream 'audio'
- 1st leg: Applying negotiated SDP media stream 'video'
- 1st leg: video:inactive (incorrect)

My question is: Which part of the code is being called that modifies the stream
states between new_invite() (where the topology and local_sdp are still
correct) and when the 180 is sent by Asterisk?

Thank you in advance,

Max