Re: Changing codec parameter dynamically

[301@xxxxxxx]

Thank you all for your answers and proposals.

Disabling sound device seems interesting but I don't see how it can work in my scenario (see below).

The pjsip keep-alive mechanism seems to be linked to VAD only as far as I understand, and the compiler setting is a constraint for me because the keep-alive period can be defined in SDP at session establishment.

To give you my scenario: I use PJSIP stack to perform "classic" telephone calls, and in parallel to perform radio calls. Those radios calls are half duplex; when one side doesn't transmit audio, it shall send some kind of keep-alive packets (without payload) at a lower frequency. So when I transmit audio, I shall receive keep-alive packets from the other side. When the other side send me audio, I'm supposed to send keep-alive packets. When nobody is sending audio, both sides shall send keep-alive packets.

If I disable the sound device when there is no audio on either side, I guess this would have an impact on the other pending calls (telephone) that the application is supporting, doesn't it? (I will loose sound on the other calls)

When I receive audio and re-enable the sound device, then I will transmit audio too, won't I?

What Gang Liu proposes is what I'm doing right now, but there is one drawback: the RTP statistics are wrong this way because they still believe that the payload has been transmitted...

I still have to find out how to retrieve the ptime used by the codec in order to determine how many RTP frames I have to drop. Nevertheless, as for the payload drop in the transport adapter, it seems not very efficient to waste such processor time with things which are not useful (making RTP frames to be dropped, making payload to be removed...).

But at least it works :-) I will see the performance impact with large number of calls...

Thibault

2016-12-03 12:36 GMT+01:00 JOHAN LANTZ <johan.lantz@xxxxxxxxxxxxxx>:

Have you thought about something like:

• When you are talking or when the other peer is talking, use the sound card as always
• When there is silence, call pjsua_set_null_snd. This way you do not block the sound device for other apps needing it and you do not consume any unnecessary power. The call stays active though and the null sound maintains the timing for the rtp flow.
• When the user presses the PTT button or when you detect incoming rtp you call pjsua_set_snd_dev to activate the sound card again and so on.
• Pjsip by default does rtp and rtcp keep alive. You can configure both the content of the keep alive packets and the frequency through compiler switches easily. That way you can configure rtp keep alive to be done every 200 msec with an empty packet. (By default when you have audio, you send audio frames every 20 msec).

/Johan

From: pjsip on behalf of Gang Liu
Reply-To: pjsip list
Date: Saturday, 3 December 2016 at 04:16
To: pjsip list
Subject: Re: Changing codec parameter dynamically

you can do it at your custom transport adapter.

for example I guess you have some application flag "without audio". when this flag enabled, drop some rtp frames and send only 200 ms. only things you need to do is

rewrite rtp seq and rtp timestamp correctly at your adapter if remote peer don't like big big packet loss.

VAD work for some codec, some wouldn't because some like "SID"  frames still sending out.

On Sat, Dec 3, 2016 at 7:12 AM, <301@xxxxxxx> wrote:

Hi,

In my project where I simulate some kind of push to talk, I need to be able to have no payload in the RTP packets when the PTT is off. I succeeded to do that by removing the payload in a custom transport adapter and the transport_send_rtp callback (but is it the best way to do that?).

Anyway my second need is to change the frequency of RTP packets when I remove the payload (PTT off). For example:

with audio: RTP frame every 20ms

without audio: RTP frame every 200ms

So I was thinking of dynamically changing the ptime of the codec in use, but I don't figure out how to do that (again this may not be the right way to do it, any other suggestion welcome then).

Could anybody give me an hint?

Thanks.

Thibault

_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

_______________________________________________
Visit our blog: http://blog.pjsip.org

pjsip mailing list
pjsip@xxxxxxxxxxxxxxx
http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org