Asterisk not sending RTP packets for H264 Video

Asterisk Asterisk Endpoints
1

My Hikvision Doorbell, model DS-KB8113-IME1(B), can successfully register to Asterisk (version 22 running on FreeBSD) and videocall my Linphone App when pressing the doorbell button.
One way video works as expected. When reviewing the log of this working call, I see RTP packets of type 96 (H264) from my doorbell, and sent to my Linphone App.
working_videocall.txt (2.2 MB)

But, the opposite direction is not working as expected. When I videocall my doorbell from my Linphone App I see RTP packets of type 96 from my doorbell, but they are not being sent to my Linphone App. Packets of type 00 (PCMU) are being recieved and sent, and two-way audio works as expected.
novideo_rtp.txt (600.1 KB)

I inspected the SIP exchanges of the videocall from the Linphone App to the Doorbell and the INVITEs a=sendonly/recvonly all make sense to me. But for some reason Asterisk is not sending the RTP packets with type 96 that it is receiving.
SIP.txt (1.0 KB)

  1. Caller initiates video call
  2. Receiver responds for video I am ‘sendonly’
  3. Asterisk relays this message to caller
  4. Caller sends invite for video as ‘recvonly’

Is it possible this is a bug with Asterisk’s handling of videocalls for the above situation? It seems like Asterisk disables both video feeds, not just the Caller’s.

Should my next step be to try to read the source code of Asterisk for this specific situation? Or should I get a Wireshark capture of the actual RTP packets? Thanks for the help!

2

One thing I noticed from comparing the logs.

The working call, with 2-way audio and one way video has…

RTP ooh, format changed from none to h264
RTP ooh, format changed from none to ulaw
RTP ooh, format changed from none to ulaw

But the non-working call, with only 2-way audio where video packets aren’t being forwarded has…

RTP ooh, format changed from none to ulaw
RTP ooh, format changed from none to ulaw

3

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

5

I found another thread with a similar issue.
[Hikvision intercom only audio]

I am starting to suspect the problem is Asterisk is interpreting the camera’s sendonly response for the video stream and putting the video stream on hold. When a call is put on hold, is that shown in the log? Is there any way I can change this behavior, either in pjsip configuration or dialplan? Otherwise I guess the only way to get this working is modify the behavior in res/res_pjsip_session.c? I don’t believe I can force my doorbell to send “sendrecv” for video, as I saw fixed similar issues for others.
Thank you

6

@josh4trunks I have reopened this original topic for discussion and merged in your new post. If you ever want to reopen a thread you can flag it.

1 Like