I'm working on a video call application using PJSIP where the goal is to receive a video feed from a doorbell camera without sending back video from my end. This setup aims to ensure privacy while allowing users to see who is at the door through the doorbell's camera. However, I've encountered an issue with configuring the media stream directions correctly.
Here's the code snippet I'm using to answer incoming calls, with the intention of setting up the call to decode (receive) video only:
var msgData = pjsua_msg_data()
pjsua_msg_data_init(&msgData)
var opt = pjsua_call_setting()
pjsua_call_setting_default(&opt)
opt.aud_cnt = 1
opt.vid_cnt = 1
opt.flag = PJSUA_CALL_SET_MEDIA_DIR.rawValue
opt.media_dir.1 = PJMEDIA_DIR_DECODING
pjsua_call_answer2(id, &opt, code, nil, &msgData)
In this configuration, I expected to only receive video from the doorbell (setting opt.media_dir.1 to PJMEDIA_DIR_DECODING). However, this does not seem to work as anticipated—I am unable to view the video from the doorbell.
I've also tried setting opt.media_dir.1 to PJMEDIA_DIR_ENCODING, which logically would not be correct for my use case as it implies sending video. As expected, this allows the doorbell to receive video from my end, but I still cannot see the doorbell's video, also when i am not setting anything to media_dir, i a'm able to see the doorbell, but in the same time i am also sending video.
How should I correctly configure the media direction in PJSIP for my specific use case?
Are there additional steps or configurations required to achieve a one-way video stream where only the doorbell's video is displayed?
Could there be other factors (such as firewall or NAT settings) that might prevent the video stream from being received, despite the media direction being correctly configured?
Any insights or guidance on how to resolve this issue would be greatly appreciated. I'm looking to ensure that the application can reliably receive video from the doorbell without sending video back, maintaining user privacy.
Thank you in advance for your help!
The issue experiencing with setting up a one-way video stream in PJSIP, where intend to receive video without sending any, is likely related to how NAT (Network Address Translation) is handled in the setup. The local SDP answer using a private IP address (c=IN IP4 192.1......) indicates that when behind NAT, PJSIP determines where to send packets based on the source of incoming packets. Without sending packets, PJSIP cannot determine the correct destination for the video stream, causing the video packets not to arrive.
To resolve this, you have two main options:
1, Enable STUN (Session Traversal Utilities for NAT): This allows your media transport to publish its mapped IP address in the SDP. The effectiveness of this method can vary depending on the type of NAT you are dealing with, so it may or may not work for your specific situation.
2, Enable Keep Alive for NAT Hole Punching: This method involves periodically sending empty RTP packets to maintain the NAT mapping for the video stream. This is particularly useful because when the media is bidirectional (i.e., you can see the video when you are also sending video), it suggests that maintaining an active route for the packets can resolve the issue. To implement NAT hole punching, you need to:
Compile-time: Enable keep alive in the media stream by setting the macro PJMEDIA_STREAM_ENABLE_KA to 1 in config_site.h. This macro is essential for instructing PJSIP to use keep-alive mechanisms for stream media. Run-time: Activate keep alive using either PJSUA's pjsua_acc_config.use_stream_ka or PJSUA2's AccountConfig.mediaConfig.streamKaEnabled option. This run-time setting ensures that the keep-alive mechanism is actively used during the operation of your application. By adopting one of these strategies, you should be able to configure your application to reliably receive video from the doorbell camera without the need to send video back, thereby maintaining user privacy. The choice between using STUN or keep-alive mechanisms depends on your network environment and the specific behaviors of your NAT.