Re: RTP timeout from a transport adapter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Johan,
My transport adapter will also be doing other stuff such as modifying the RTP packets. My question was more aimed at the "you would probably need some polling anyway" comment. Why would polling be necessary? Is there some reason why timers wouldn't be the best option to handle timeout from a transport adapter?

Kal

On Fri, Aug 19, 2016 at 9:54 AM, JOHAN LANTZ <johan.lantz@xxxxxxxxxxxxxx> wrote:
Looking at the answer I see that it was me replying a couple of years back.

I think my comment today is the same. You can certainly put this in a transport adapter but if you use pjsua it might be a little bit strange approach since the adapter would sit at a layer a bit down from the pjsua API that you would finally use to hang the call but it is certainly doable.

I have just implemented it with a pj_timer (sitting on top of pjsua) that checks the rtp stats and if there are no packets arriving during an interval you find reasonable you simply hang the call. 

Johan

From: pjsip on behalf of b17 c0de
Reply-To: pjsip list
Date: Thursday 18 August 2016 at 22:57
To: "pjsip@xxxxxxxxxxxxxxx"
Subject: RTP timeout from a transport adapter

Hi,
I am implementing a transport adapter that will (among other things) handle RTP timeout. Does anyone here have any insight on the easiest way to handle this? I have read the post here: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2012-March/014274.html. In this post it is commented that with a transport adapter "you would probably need some polling anyway" to handle the timeout. Why would polling be needed? How could you control the resolution of the polling? Are there any issues with just using the pj timer heap api to handle timeout here?

Regards,
Kal



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

_______________________________________________
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

[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux