I’m trying a video call, from gds softphone to a face recognition device, that send always payload 96 in 200 OK response and cannot be changed. Don’t matter what payload the softphone send in sdp, asterisk always send 99.
I’m think that’s the reason the video is not working. Do anyone know how force asterisk to send a 96 payload in the INVITE?
With an IP phone that send 99 payload in 200 response to asterisk, this same video call works well.
You may be able to set the payload type in the configuration of the softphone. I think Asterisk hands over only the payloads it receives from the endpoints.
I have a various phones, where sometimes you can set only the payload for the DTMF sequences, and sometimes for pretty much everything (Grandstream GXV3275) including the H.264 payload type.
Hello!
In version 11.25.3 it worked, choosing payload 96 on the softphone. But the video is loaded with losses and delays, making it unacceptable.
I can see in wireshark that rtp packets received by asterisk as Payload type= DynamicRTP-Type-96 (96), are not sent to the other side (softphone)
In this same scenario, I used an ip phone with payload 96.
Even configured this way, it responds to asterisk’s invite with 99 and the exchange of rtp packages between them, happens in such a way.
Then asterisk sends the packets to the other side (softphone) as Payload type: H264 (96). And the video call is perfect.
In the face recognition device aren’t options to change payload type, so the only way is to make asterisk accept and forward this PT=DynamicRTP-Type-96.
But I do not know how.
Asterisk is a back to back user agent. Except as special optimisations, ingoing and outgoing media are independent.
In any case, the device is the one that is behaving badly, not Asterisk. The device should match the media based on the rtpmap line and should have no pre-conceived ideas about anything from 96 upwards. The RFCs are a little odd about its responding with 96. This is bad practice, but the only real rule seems to be that it cannot use 99 for anything other than that media type on that stream, although I think there is a strong hint that it should not use two different numbers for the same media type.
It does seem to have changed the profile level, so that might really be a different stream type, and therefore need a different codec number.
I imagine that the only way of forcing Asterisk to use 96 is by redefining 96 to be a static code, in the source code, but, if the real problem is the profile-level-id change, by the device, that might not help
Hi, Thanks for your reply.
You mean the device should respond with 99 in 200 response to asterisk? Because I think it should, but payload it’s not a configuration option on that side.
The profile-level-id caught my attention. I don’t know exactly its effects on the flow. Maybe you’re right, that might really be a different stream type, and therefore need a different codec number.
Anyway, thanks a lot.