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!

Help with Hikvision Doorbell Registered to Asterisk
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
7

Hi @josh4trunks , Iā€™ve found the most likely cause for the video issue. Apparently Hikvsion devices are not able to negotiate media, they are fixed on sending H264 as PT 96 no matter what so they always answer 200 OK with that map. In your case, I think you are using Asterisk as a SIP-Proxy, so when the Linphone offers media, itā€™s most certainly offering H264 in another PT, so at the end no negotiation is made. So Asterisk is expecting packets with the payload type that the Linphone offered and the device is just sending H264 in PT 96.

I have a similar issue with my Hikvision device, I use Asterisk as B2BUA, so when Asterisk sends the invite to my leg B (Hikvision device), it offers H264 PT 99, the device ignores this and still sends the 200 OK with H264 PT 96, so Asterisk receives the packets and doesnā€™t know what to do with them. I have this configuration in pjsip but Asterisk is still refusing to sends the packets to the other leg:

codec_prefs_incoming=prefer:remote,operation:intersect
codec_prefs_outgoing=prefer:remote,operation:intersect
asymmetric_rtp_codec=yes

I think this pinpoints the actual source of the problem but I havenā€™t found a solution yet. I would be really grateful if you could give me a solution @jcolp. This problem is driving me crazy

8

Thanks @scuartas youā€™re right!

Though, I am also using Asterisk as a B2BUA. But clearly Asterisk sending Hikvision m=video with PT of 99 and the Hikvision device is not responding correctly.

Iā€™ll look more into the settings you listed. We basically need asterisk to handle this broken device somehow =[

9

If Asterisk makes a first offer of payload type 99, that is the only payload type it should receive, If the HikVision makes a second offer of 96, thatā€™s what it expects to receive and is unrelated to what it should send. Itā€™s basically broken. You would have to hack the code, in Asterisk, specifically for this broken endpoint. Itā€™s not something Iā€™d expect you to be able to work round with .conf files

(Actually, I think there is a standard that says the response offer must use the same payload type as in the offer, if it is intending to receive using the same codec.)

10

We could submit a bug to Hikvision, they did add unlocked SIP feature in the past to some doorbell firmwares.

But, I am not sure how willing they are to address this bug, since it probably doesnā€™t affect their supported install method of connecting to their intercom/monitor (which acts as a SIP server).

11

Isnā€™t there a way to modify the internal mapping of Asterisk to offer H264 in PT 96? Or is there any B2BUA that could do this?

12

@scuartas the settings you configured seem to be old. It looks like the relevant settings are nowā€¦

codec_prefs_incoming_offer
codec_prefs_outgoing_offer
codec_prefs_incoming_answer
codec_prefs_outgoing_answer

Maybe what we could do is not list h264 as an allowed codec for hikvision. Then asterisk never assigns it a PT in the outgoing offer. But then assuming hikvision still responds with h264(PT=96) we prefer that codec from the answer.

I donā€™t have time to produce logs at the moment to test. But maybe can look more into this next week.

Also I noticed this sentence in the documentation; so not sure if these settings actually do anything.
ā€Note that this option is reserved for future functionality.ā€

13

Payload type 96 is the start of the dynamic types range, so there is no fixed mapping between H.264 and a payload type. It will depend on the order in which the types are processed, and any which Asterisk itself reserves.

You can probably modify the code to, effectively reserve 96 for H.264. Thatā€™s what I meant by ā€œhack the codeā€. This is not a normal thing to do, so will involved a more detailed knowledge of this part of the code than I currently have.

14

The PT in the answer is the one that the Hikvision wants to receive (except it wonā€™t actually be expecting to receive, as it is a camera, not a display, so probably should be sending ā€œa=sendonlyā€). I donā€™t think there is anywhere in the RFCs that would allow Asterisk to accept that as the payload time for a stream on which it had not offered that as a payload type for the media type in question.

15

Iā€™m going to be setting up an AIphone video doorbell next week - just a FYI - Aiphone seems to be very friendly to Asterisk/FreePBX - based on what I have found out already in talking to their support people. Iā€™ll be running that to Cisco 8845 videophones which prefer H.264 - Iā€™ll report back my experiences. If your Hikvision stuff is still within the 30 day return window, perhaps that would be the best solutionā€¦the Open Source community in general has gotten better manufacturer response by refusing to buy stuff that isnā€™t supported with Open Source, than to work around makers who ignore itā€¦just sayinā€¦

16

I tried the settings you suggested but unfortunately they didnā€™t work. I ended up changing the Asterisk source code to remap the default PT for H264 to PT 96 and itā€™s working now.

17

Ok, after this week I should have some time to experiment with the settings. I would prefer to fix this with standard settings, since any source changes will need to be maintained between updates. But, at least we know hardcoding 96 works.

18

Iā€™m definitely past my return window lol. I bought my video doorbell on some Chinese marketplace site for $50. Itā€™s normally at least $120 I would think; I was surprised it was actually Hikvision and not a knock-off or rebrand.

I agree we should support companies that work with open source. But in this case, I knew the doorbell supported SIP (but with bugs!), and liked the vandal resistant design of the model I purchased. Plus Iā€™m used to Hikvision since them and Dahua, make the best image quality security cams.

19

>Plus Iā€™m used to Hikvision since them and Dahua, make the best image quality security cams.

Both companies have been implicated in spying for China PRC:

Court upholds FCC right to ban tech from Chinese-owned telecom companies | The Record from Recorded Future News

Make sure to set a static IP on your video doorbell and put an access list in your Internet router blocking the doorbell from access to the Internet. People noticing traffic going from their Hikvision stuff to IP addresses in China was what tipped off the federal government that something was amiss.

20

Please put this patch as an issue in the github repo for the Asterisk source code, thanks! It may never be integrated into the source code but putting it there allows others to make use of it. Donā€™t post it here.