linphone-developers
[Top][All Lists]
Advanced

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

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


From: Mark Mickan
Subject: Re: [Linphone-developers] oRTP, multiple RTP streams and silence suppression
Date: Mon, 13 Mar 2006 18:40:23 +1030
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

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);
}





reply via email to

[Prev in Thread] Current Thread [Next in Thread]