Re: [Linphone-developers] oRTP, multiple RTP streams and silence suppression

[Simon Morlat]

Hi,

I'm sorry for the bug... but for my point of view it is not completely an oRTP 
bug.
The correct way to build an application over ortp is to use CFLAGS and LIBS 
from `pkg-config --cflags ortp` and `pkg-config --libs ortp `
which gives:
pkg-config --cflags ortp
-D_REENTRANT -DORTP_INET6

I agree that this is very confusing, so maybe I'll put back those macros into 
a delivered .h file, but automake/autoconf doesn't allow very much this kind 
of thing.
Also I can put mask_pos to a place that it is not compile-dependant.

Thanks for finding out this nasty problem.

Simon

Le Lundi 13 Mars 2006 09:10, Mark Mickan a écrit :
> Hi Simon,
>
> I've solved my problem, and I'd call it a bug in rtpsession.h:
>
> Within the definition of the the RtpStream structure, there are two
> options for rem_addr, one when ORTP_INET6 is defined, and one when it is
> not.  The two options are different size data structures, resulting in a
> different sized RtpStream depending on whether or not ORTP_INET6 is
> defined at compile time.  Since RtpSession includes an RtpStream typed
> variable before mask_pos in its struct definition, mask_pos will be at a
> different offset depending on whether or not ORTP_INET6 is defined
> during compilation.
>
> This affected my code because the library was compiled with ORTP_INET6
> defined, but my code was not.
>
> The same error appears in the RtcpStream structure definition too.
>
> Either these alternative structures need to be the same size (by adding
> padding within the #ifdef ORTP_INET6 #else #endif), or that variable
> needs to be defined in the .h files for installations where the library
> has been compiled with that flag set.  I'm not an expert with autoconf,
> so you might have a better idea, but perhaps an ortp/config.h file
> generated by the configure script that is #included at the top of each
> ortp/*.h file?
>
> Cheers,
> Mark
>
> Mark Mickan wrote:
> > Hi Simon,
> >
> > Yes, I do see rtp_session_recvm_with_ts() returning NULL when there is
> > no data to read due to the silence suppression.
> >
> > I've run ethereal on the calls as you've suggested and I'm seeing
> > significantly more packets with ethereal than the oRTP statistics are
> > reporting.  I also tried it with one call (the scenario that works) to
> > double check that I was reading the right figures from ethereal...
> >
> > With 1 call, both ethereal and oRTP reported 110 RTP packets.  With 2
> > calls, ethereal reported 219 RTP packets while oRTP reported only 127.
> >
> > I'm using ortp-0.9.0-pre1.
> >
> >
> >
> >
> > I've tried to get you some more information to go with this using gdb
> > and large numbers of debugging messages and believe I have something
> > useful: both RtpSessions have a mask_pos of 0.  What I cannot
> > understand is why this is the case... before returning from
> > rtp_session_set_scheduling_mode, the second RTP stream actually does
> > have a mask_pos of 1 as should be the case.  However, immediately
> > after returning from that function to my code, a printf shows it as
> > being 0 again.  From what I understand of the oRTP library, this would
> > produce the behaviour we are seeing.
> >
> > Here's the output from my debugging:
> >
> > 2006/03/10-17:22:26.718030 SipControl.cpp:1340: INFO: created new
> > rtp_session 0x82d5e60
> > session=0x82d5e60, mask_pos=1 in rtp_session_set_scheduling_mode
> > 2006/03/10-17:22:26.718046 SipControl.cpp:1342: INFO: call->rtp =
> > 0x82d5e60, mask_pos = 0
> >
> > ...and here's what I've done to the code to produce these messages:
> >
> > // in my code at the rtp_session_set_scheduling_mode() function call
> > INFO("created new rtp_session %p", call->rtp);
> > rtp_session_set_scheduling_mode(call->rtp, 1);  // enable scheduling mode
> > INFO("call->rtp = %p, mask_pos = %d", call->rtp, call->rtp->mask_pos);
> >
> > // in rtpsession.c, in the rtp_session_set_scheduling_mode() function
> > if (sched != NULL)
> > {
> >    rtp_session_set_flag (session, RTP_SESSION_SCHEDULED);
> >    session->sched = sched;
> >    rtp_scheduler_add_session (sched, session);
> >    // this printf line added...
> >    printf("session=%p, mask_pos=%d in
> > rtp_session_set_scheduling_mode\n", session, session->mask_pos);
> > }
> >
> >
> > I've been able to reproduce this behaviour in a very small program
> > (attached) on both a centos and a debian machine running the
> > 0.9.0-pre1 oRTP library.  Compile and link it to the oRTP library and
> > you'll see that the second rtp session has a mask_pos of 0 after
> > calling rtp_session_set_scheduling_mode() even though it has the
> > correct value immediately before exiting that function!  I've stepped
> > through it in a debugger and cannot work out how this could happen.
> >
> > Any ideas?
> >
> > Thanks,
> > Mark
> >
> > Simon Morlat wrote:
> >> Everything seems fine here...
> >> I'm a bit surprised with the second statistics: with 2 call
> >> simulatenously we have received only 125 packets while in the first
> >> case (one call) we received 109 packets.
> >>
> >> The correct behaviour of session_set_select() it is to sleep until it
> >> is time to recv something on one of the session in the set.
> >> The time to recv something is computed from the timestamp interval
> >> given in the rtp_session_recvm_with_ts().
> >> As your application uses 160 timestamp steps, the expected behaviour
> >> is that session_set_select() returns every 20ms with the two sessions
> >> int the recv set.
> >> If there is no data to read on the socket because of silence
> >> suppression (untransmitted packet), thus rtp_session_recvm_with_ts()
> >> will return NULL.
> >> Is that what you observe ?
> >>
> >> The statistics shows that every packet received has been delivered to
> >> the application.  You try to match the number of received packets
> >> according to oRTP and the number of packets send to your host
> >> according to a network sniffer such as ethereal.
> >>
> >> By the way, what version of oRTP do you use ?
> >>
> >> Simon
> >>
> >> Le Jeudi 9 Mars 2006 06:49, Mark Mickan a écrit :
> >>> Hi Simon,
> >>>
> >>> I've added your suggested debugging code.  Here are my results:
> >>>
> >>>
> >>> Running one call through it (one call at a time is successful):
> >>>
> >>> rtp_session_recvm_with_ts returned NULL every 20ms for the periods
> >>> (times are in HH:MM:SS.microseconds format):
> >>> 13:13:13.308719 - 15:13:18.440292   (total 5.131573 seconds)
> >>> 15:13:18.901060 - 15:13:27.501688   (total 8.600628 seconds)
> >>>
> >>> ortp-message-oRTP-stats:
> >>>   Global statistics :
> >>> number of rtp packet sent=688
> >>> number of rtp bytes sent=118162 bytes
> >>> number of rtp packet received=109
> >>> number of rtp bytes received=18748 bytes
> >>> number of incoming rtp bytes successfully delivered to the
> >>> application=18232
> >>> number of times the application queried a packet that didn't exist=691
> >>> number of rtp packets received too late=0
> >>> number of rtp packets skipped=0
> >>> number of bad formatted rtp packets=0
> >>> number of packet discarded because of queue overflow=0
> >>>
> >>>
> >>> Running two calls through it simultaneously (first one succeeds, second
> >>> one fails):
> >>>
> >>> rtp_session_recvm_with_ts returned NULL every 20ms for the periods
> >>> (times are in HH:MM:SS.microseconds format):
> >>> Call 1: 15:33:25.807180 - 15:33:30.960897   (total 5.153717 seconds)
> >>> Call 1: 15:33:31.421154 - 15:33:39.961239   (total 8.540085 seconds)
> >>> Call 2: 15:33:32.981678 - 15:33:38.140587   (total 5.158909 seconds)
> >>> Call 2: 15:33:38.602090 - 15:33:41.581084   (total 2.978994 seconds)
> >>>
> >>> Note that the last time we get a NULL returned from
> >>> rtp_session_recvm_with_ts coincides with the end of the 1st call.
> >>>
> >>> ortp-message-oRTP-stats:
> >>>   Global statistics :
> >>> number of rtp packet sent=1725
> >>> number of rtp bytes sent=296338 bytes
> >>> number of rtp packet received=125
> >>> number of rtp bytes received=21500 bytes
> >>> number of incoming rtp bytes successfully delivered to the
> >>> application=21156
> >>> number of times the application queried a packet that didn't exist=1095
> >>> number of rtp packets received too late=0
> >>> number of rtp packets skipped=0
> >>> number of bad formatted rtp packets=0
> >>> number of packet discarded because of queue overflow=0
> >>>
> >>>
> >>>
> >>> Not sure what to make of this myself...
> >>>
> >>> Thanks,
> >>> Mark
> >>>
> >>> Simon Morlat wrote:
> >>>> Hi,
> >>>>
> >>>> You code seems correct.
> >>>> Can you add some printf to see if rtp_session_recvm_with_ts()
> >>>> returns NULL
> >>>> packets during the silence period ?
> >>>> Can you print the statistics by calling ortp_global_stats_display() ?
> >>>>
> >>>> Simon
> >>>>
> >>>> Le Mercredi 1 Mars 2006 04:33, Mark Mickan a écrit :
> >>>>> Hi all,
> >>>>>
> >>>>> I'm having some problems with oRTP when handling more than one RTP
> >>>>> stream containing silence suppression.  The (attached) code works for
> >>>>> multiple streams without silence suppression, but not with.  It also
> >>>>> works for one stream at a time with silence suppression.
> >>>>>
> >>>>> Each stream is a burst of audio followed by a short silence
> >>>>> followed by
> >>>>> a burst of audio with the marker bit set on the first packet.
> >>>>> Specifically, it is produced by Asterisk doing a Record() followed
> >>>>> by a
> >>>>> Playback().
> >>>>>
> >>>>> I start the second stream about 5 seconds after the first one is
> >>>>> started
> >>>>> and each stream is a total of about 30 seconds.  I've narrowed it
> >>>>> down
> >>>>> to the code blocking on the session_set_select() after the first
> >>>>> stream
> >>>>> has finished and when it should be receiving the second burst of
> >>>>> audio
> >>>>>
> >>>>> from the second RTP stream.
> >>>>>
> >>>>>
> >>>>>
> >>>>> Could this be a bug in oRTP, or am I doing something wrong?
> >>>>>
> >>>>> Many thanks,
> >>>>> Mark
> >
> >------------------------------------------------------------------------
> >
> >#include <ortp/ortp.h>
> >
> >int main(int c, char **v)
> >{
> >     RtpSession* rtp1;
> >     RtpSession* rtp2;
> >
> >     ortp_init();
> >     ortp_scheduler_init();
> >
> >     rtp1 = rtp_session_new(RTP_SESSION_SENDRECV);
> >     printf("created new RtpSession* rtp1=%p (mask_pos=%d)\n",
> >                     rtp1, rtp1->mask_pos);
> >
> >     rtp_session_set_scheduling_mode(rtp1, 1);
> >     printf("rtp1=%p, mask_pos=%d after setting scheduling mode\n",
> >                     rtp1, rtp1->mask_pos);
> >
> >     rtp2 = rtp_session_new(RTP_SESSION_SENDRECV);
> >     printf("created new RtpSession* rtp2=%p (mask_pos=%d)\n",
> >                     rtp2, rtp2->mask_pos);
> >
> >     rtp_session_set_scheduling_mode(rtp2, 1);
> >     printf("rtp2=%p, mask_pos=%d after setting scheduling mode\n",
> >                     rtp2, rtp2->mask_pos);
> >
> >     exit(0);
> >}
>
> _______________________________________________
> Linphone-developers mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/linphone-developers