How to get video preview?


I want to understand how a doorphone system should be setup to get video preview.

I’m looking at RFC 3960: Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)

1. Introduction Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user.

If endpoint device maker says “it follow the RFC standard”, my concern now it is asterisk is able to manage this kind of transaction?

From asterisk is only the Progress() needed in dialplan?

Thanks in advance.

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.

Thanks, BR

Can please someone say me if this sip message should be sent from the UAC and so I cannot do anything about it on PBX?

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.

Thanks for reply, if I’ve understood:

  • UAC is the doorphone
  • UAS is the phone
  • asterisk is the back to back user agent.

UAS maker said only:

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.

UAS as “the phone”, I believed was the phone maker that should say how their product is handling the preview feature.

I’m sorry but I haven’t understood that the B2BUA is able to edit what’s going on in the transactions.

I will look to that app_dial patch, thank you

I’m not a developer, I’ve found out this post about the topic:

Found out the source file at:

Can you please tell me what edit is needed before starting to compile?

Thanks, BR

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.

The CAN_EARLY_BRIDGE part is defined by:

#define CAN_EARLY_BRIDGE(flags,chan,peer) (!ast_test_flag64(flags, OPT_CALLEE_HANGUP | \
	!ast_channel_audiohooks(chan) && !ast_channel_audiohooks(peer) && \
	ast_framehook_list_is_empty(ast_channel_framehooks(chan)) && ast_framehook_list_is_empty(ast_channel_framehooks(peer)))

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.

Ah, where is that patched file? do you have a link somewhere?

I have a testserver, if i look in that “app_dial.c” file
Gonna remove it from here:
line :1579 + 1548

						if (single && !caller_entertained
							&& CAN_EARLY_BRIDGE(peerflags, in, c)) {
							ast_channel_early_bridge(in, c);

Lets see what happens :slight_smile:

As I said in my last post:

yeah, i’m already looking for a long while to have early media in group calls, never found a patched file :slight_smile:
But anwyay, compiling now :slight_smile:

ok, removing single didnt work, that would be too easy :slight_smile:
if you ever find that patched file, lemme know!! :slight_smile:

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.

Yeah, that’s out of my league :slight_smile:

I need some help of a developer here