The SIP RFCs only relate to the parts of the system that are using SIP. Asterisk is a back to back user agent, and the bit between them is not SIP. Looking at the source code for app_dial, I see no support for video as early media, although I haven’t checked in enough detail to completely eliminate the possibility that it is handled by catchall code.
I have a feeling that the ARI primitives do support an early media bridge, but I’m no certain of that.
I assume you are talking of media from the doorphone, and the doorphone is the UAC, as, going against the call setup direction would also require early offer SDP (which is the more common case).
Thanks @david551 for reply, yes I’m referring to video sent from the doorphone.
I’ve tested that with differents endpoint device, someone, is able to choice the kind of signal that it need to use for preview (i.e if it choose to consider 2xx SIP for preview ) the video is correctly displayed (I know this means the call is picked up, but works fine for some usecase).
But the more I read the more I’m gettings confused: ie. 3.3. Absence of an Early Media Indicator…
Can you please point me out to what you mean with: “Asterisk is a back to back user agent, and the bit between them is not SIP”?
Incidentally, I’m not sure why you need to leave the doorphone in an early media state, not that that will help with the early media state of the callees.
I’m trying to understand how to get video preview, my vendor doesn’t provide any help or documentation about it.
They’ve just said: have you enabled “early media and video preview” option?
I’ve googled those and just came out to “Early media” as in it’s description says
“If the UAC receives early media from different UASs, it needs to present it to the user. On the other hand, other media types (e.g., video) can be presented to the user at the same time.”
I’m triyng to understand if I can try something on the PBX (I’m just a devop).
As you can imagine, in a doorphone system a working video preview, many times can avoid the call at all. The user see and push the open button without answering.
This is a working example, the doorphone call directly the phone, the phone after the 183 send backt to doorphone INFO, but trought PBX this never happens.
It’s a response and responses can only ever sent from a UAS.
However, I would note that many people try and identify client with phones, and server, and server with PABXes, even though both of them take on both roles, depending on the direction of the call.
Also, the actual SIP RFC only contains the first paragraph:
and the only references to early media are with respect to Content-Disposition, which, in practice, I don’t think people use. Early media can be set on any response (or request).
Regarding the RFC 5168 INFO, it would appear that this is deprecated, in favour of RTCP, so I’d say that it is at best a MAY, not a SHOULD. The UAS doesn’t have honour this. The RFC seems to be about forcing a full retransmission of a video frame, and on a quick reading it is the frame towards the requester.
So to get an example of a working SIP flow to reference for video preview there’s nothing explicit in the RFC.
The only one that can do something about it is the UAS?
Which UAS? Asterisk is both UAS and UAC in this call. As I already said, the bit between the UAS and the UAC is outside the scope of the SIP RFC, because it is a back to back user agent.
I seem to remember someone patching app_dial.c, to forward video frames as early media.
I didn’t notice that big of code, but note the “if (single…”. A lot of people with doorphones seem to want to call multiple destinations, which means single = false, and the code has to fall back to the original app_dial logic, where app_dial, itself, does the early bridging.
The function it calls takes two channels, so there can be a maximum of two channel involved in the call. I don’t know if it bridges video but it seems likely it does.
Which means you can’t have any of the A, H, h, K, k, T, t, U, w, or W flags, you can’t have, probably amongst other things, MixMonitor set on either channel, and there is something about frames that is new to me.
I think it also said the caller can’t be entertained, which means you can’t have m, r, and presumably R.
@Summer => i was struggling with early media too, i have a doorintercom that sends video in 183 session, but my softphones never see it,… by just adding progress() it works , so i can see video + audio before picking up, but only on 1 to 1 calls …
@david551 do you think by just removing the keyword ‘single’ from that IF method, 1 to n (group calling) will work? is it that easy ??
Bridges tend to be synchronous, although my experience of them is from before the great bridge rework and introduction of the early media bridge. If it is synchronous, only the first outgoing channel will be looked at until that one answers, so it will effectively become “single”. If it is asynchronous, channels aren’t supposed to be in more than one bridge, so there is a good chance it will crash and burn, and, at best, you will get the video frames distributed randomly amongst the callees, with only one callee getting any one frame. You would also get an unholy mess or all the early media in the reverse direction being sent to the doorphone, at n times the normal frame rate.
The “single” constraint is there because things will only work in that case.
As I already said, I think someone patched the early media code in the core of app_dial. Although I don’t think that is difficult, I’m not going to take responsibility for providing untested code, and provide any more details. It will probably take me as long as you to find the relevant thread. As far as I can see, the only real reason for not allowing it is the potentially large network bandwidth used; I think any official patch would require an option to enable it at run time.
You would need to add code to handle AST_FRAME_VIDEO to the main processing. You might also need to handle AST_CONTROL_VIDUPDATE in the reverse direction but that might create big bandwidth problems if done naively.
