Early media with video comes up every few months at this point, and it’s not something anyone has invested time into. It’s not supported. There is supposed to be code to handle certain situations, but it doesn’t seem to work, or things need to be implemented elsewhere.
This topic has been brought up on the Asterisk forum several times. I’m not certain if anyone got a solution, but app_dial does not have any code to handle video.
How many endpoints are you ringing? I seem to remember that Dial will use an early media bridge, rather than its own relay code, when there is only a single destination, so might be more likely to relay early video, in that case.
I should also point out that Asterisk is a back to back user agent, and does not forward SIP requests as such. 183 would be turned into AST_CONTROL_PROGRESS, which has no information about specific media types. This is what actually puts DIal into early media bridge mode, but only if there is only a single destination being called and only if no Dial options for ring back or music on hold, have been set (caller is not being entertained).
There are some rules, I believe, about having to have explicitly called the Progress() application, but that might be what the inband_progress option does.
Dial doesn’t, itself, generate AST_CONTROL_PROGRESS if it uses an early bridge, and, as I said, will throw away video frames if it bridges internally,. I haven’t checked ast_channel_early_bridge(), to see if that send AST_CONTROL_PROGRESS, but I think the log messages dates from before the big bridging rework, so was added before ast_channel_early_bridge() ever existed.
Dial is actually being naughty, as it is not testing whether ast_channel_early_bridge failed. It is possible that there are reasons that would not be picked up by the preceding macro call.
In any case ast_channel_early_bridge is very small, and all the work is done by the channel driver of, in this case, the caller’s channel, so the behaviour may differ between chan_sip and chan_pjsip.
Not sure I fully understand this. Are you saying that if we see in the log PJSIP/66413-00000006 is making progress passing it to PJSIP/5507-00000005 it means that “something” (like inband_progress) has done the early bridges?
If you are referring to the dates of the logs I have posted above, it is from the past Friday.
Thinking if it is worth a shot trying this with chan_sip…
There hasn’t been any change to early bridging in Dial(). It doesn’t use the newer bridging framework for early media, it uses the same thing it has used probably since the dawn of its existence. It’s all done inside of it.
The ast_channel_early_bridge function isn’t the new bridging framework, it actually predates it. It is what is used for the “directrtpsetup” functionality in chan_sip. This is not implemented for chan_pjsip, and calling that will do nothing.
De facto, it means the Dial() application has received AST_CONTROL_PROGRESS from the outgoing channel driver. AST_CONTROL_PROGRESS is generated by the channel drivers for SIP when they receive a 183 response, but none of the other information from the response is included.
Historically, DIal, would have called ast_indicate, on the incoming side, with AST_CONTROL_PROGRESS, if there were no contraindications. The current versions seem to have the option of calling ast_channel_early_bridge, without indicating PROGRESS, although JColp has challenged that.
Some time, over five years ago, there was a big rewrite of the internals of bridging in Asterisk. Before that the only option for DIal was to do the early media bridging itself.
This is speculation, but it is possible that the change was tested on chan_sip and it was overlooked that it didn’t work on chan_pjsip.
Assuming that the macro will prevent this path being taken, it looks like most of what forwarding progress means is related to DAHDI channels, with Dial itself generating the tone signals, at a low level. It looks like, with SIP, it will only indicate progress if it was previously indicating ringing, although I’ve not checked that assumption in detail.
However, the key point is that Dial does not early bridge video, so regardless as to whether or not it has sent an indication that it is prepared to accept early media, video will not work.
I think my problem there was that Google gave me a fork that didn’t support AST_FRAME_VIDEO, and I didn’t recheck on the main github. Oops.
Note that the second link indicates that video will be suppressed if Dial has been requested to send ringback before the callee indicates ringing, or it has been requested to send music on hold. The music or ringback will take precedence over early media.
Looking more closely the early_bridge call doesn’t terminate the processing of PROGRESS, so it doesn’t matter if the macro correctly indicates that the feature isn’t available.
The only place the code is actually doing anything that would cause the channel driver to send 183 is actually conditional on DIal not having been asked to send ringback before it receives RINGING. As you only have a single outgoing channel, the behaviour you are getting, assuming an Asterisk that is recent enough to forward video, is consistent with your having asked to return ringback to the doorbell before the callee has indicated ringback.
According to your log, you are, in fact, asking Dial to send ringback before it gets RINGING, although I don’t know FreePBX well enough to know where that is coming from. See the r option, in the following.