Re: Strict RTP timing

[Кирилл Трофимов <ktrofimo@xxxxxxxxx>]

I found the reason of SEGFAULT when I try to make a second call - It happens because of the pjmedia_master_port_destroy( ) call since it kills conference where it is connected to. This function call is a part of the PJSUA library. This library already does a lot of good stuff, but the problems with this library are:

1) during initial startup a special conference is set up for resampling. While master port is initialized later - when call is established. There is no reason to create port before call made because there is no need in sound while idle. 

2) I was thinking about set up a second conference with similar parametrs, and it works without SEGFAULT but there is no sound too. Some sound ports have to be connected, but I could not find right sequence for now. I feel there should be no need in a second conference, but I may be wrong. 

Looking for your help!

Thanks!

воскресенье, 17 июля 2016 г. пользователь Кирилл Трофимов  написал:

Hello!

I building a small streaming application based on PJSIP 2.5 stack. At first I was little bit confused by the way of using it with Qt projects as a VC compiled library. I was able to rebuild whole library with Qt+mingw for Windows.

My app is now working fine, except RTP timing has some jitter - packets dalay vary from 10 to 30 ms. It is not bad at all, but my VoIP provider suggesting to fix it at 20ms. I found solution in your FAQ at https://trac.pjsip.org/repos/wiki/FAQ#tx-timing with help of splitcomb and master port. This solution gives perfect timing. Delays are now mostly in range 19..21 ms.

First problem was - SEGFAULT after hangup because clock thread was not closed properly. I was able to fix it by adding the following lines in the pjsua_aud.c, function close_snd_dev(void), after line #1927:

if( m )

{

    pjmedia_master_port_stop( m );

    pjmedia_master_port_destroy( m, PJ_TRUE );

    m = NULL;

}

One problem I am facing now - I got a SEGFAULT when I try to make a second call after first one is over. Here is a screenshot of the faulted call to pj_mutex_lock( conf->mutex ); in conference.c, line #765: https://s31.postimg.org/hyg27c5p7/image.png

Can somebody describe correct procedure of closing such kind of calls? How to fix this problem?

Thanks!

Kirill

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

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