ASTERISK-02815: [branch] RTCP-support

[Home]

Summary: ASTERISK-02815: [branch] RTCP-support

Reporter: Filip Olsson (folsson) Labels:

Date Opened: 2004-11-15 12:17:37.000-0600 Date Closed: 2008-01-15 16:34:48.000-0600

Priority: Major Regression? No

Status: Closed/Complete Components: Core/General

Versions: Frequency of
Occurrence

Related
Issues:

Environment: Attachments: ( 0) asterisk-1.2.4-rtp_c_9060_3_try2.patch
( 1) rtcp-rtp_stun_no_debug.patch

Description: This bug adds _some_ support for RTCP in rtp.c. It's not complete, but atleast it's a start.

There are a number of stuff that needs work, such as transmission intervals.

****** ADDITIONAL INFORMATION ******

Adds the CLI commands rtcp debug [ip <IP[:port]>] to print the contents of RTCP packets.

I've got a patch(very small) for chan_sip to put some statistics that we get from the RTP/RTCP-packets in the userfield of the CDR.

Comments: By: Filip Olsson (folsson) 2004-11-15 12:22:09.000-0600

It would be useful to be able to dump the contents(or a summary) of a RTCP-packet to some log so we can see how the delay/jitter/loss has changed during the call. If we just get the syncing right this could be used to correlate temporary bad sound of a recorded call to an actual event.
By: Filip Olsson (folsson) 2004-11-15 12:57:31.000-0600

Forgot to mention that this patch modifies the RTP-debugging support, it now prints the textual representation of the payload of each packet.
By: Brian West (bkw918) 2004-11-15 14:41:43.000-0600

diff -u on rtp.h
By: Brian West (bkw918) 2004-11-24 20:01:26.000-0600

any update? I would like to see broader support for this in asterisk... it would be great...
By: schurig (schurig) 2004-12-06 06:34:33.000-0600

> It would be useful to be able to dump the contents(or a summary) of a
> RTCP-packet to some log

You can use tcpdump or ethereal or tethereal to save packet traces with time stamp into a file, using various formats. That can later be analyzed.
By: Clod Patry (junky) 2004-12-16 22:22:23.000-0600

folsson, more then 1 month without any news from you. Are you still working on this or did you lost your interest to that bug?

I agree that would be great to see that kind of debug.
By: Filip Olsson (folsson) 2004-12-25 20:25:40.000-0600

Would someone like to give me some kind of feedback on this one? Crash? Does someone have it working at all(except me)? Suggestions on functionality?
By: Filip Olsson (folsson) 2004-12-25 20:29:08.000-0600

schurig: Concerning dumping stuff with tcpdump(or something else). Why do we have the CLI command 'sip debug' and all the other ones? One can always use tcpdump to dump stuff, but associating it with a specific call on a wider(more general) basis is more tricky to do with tcpdump.
By: Mark Spencer (markster) 2004-12-28 15:38:07.000-0600

I think this patch looks promising. Why is the statistic reporting routine called "pre_destory"?
By: warp (warp) 2005-01-06 11:03:27.000-0600

Without support RTCP, some gateways (VocalTec and maybe more) drop call after ~60sec. Therefore this or other patch realizing support RTCP is necessary first of all for compatibility.
By: Filip Olsson (folsson) 2005-01-06 20:20:38.000-0600

Sorry for not responding faster.
Seems there are a number of people at least interested in RTCP-support, but haven't had any feedback from people trying it.
Would someone care to test the patch? It probably won't compile right on latest HEAD, but I shouldn't be that hard to fix. I'll fix it if someone promises to apply it. :)
The compatibility is somewhat limited as it's only been tried with 42Networks DRG-line and AudioCodes MP-line. Sometimes the AudioCodes-box reports malformed RTCP-packet in it's log, nothing serious.
Markster: concerning the naming of that function, I think it was because that's the function that chan_sip calls before(pre) calling rtp_destroy. I'll gladly change the name to better reflect what it actually does.
By: Filip Olsson (folsson) 2005-01-06 20:23:25.000-0600

Oh... If someone wants to have that statistics-reporting stuff in chan_sip. Just tell me so and I'll post a patch or something. I don't have a patch against HEAD at the moment but if someone cares I'll get it out here.
By: warp (warp) 2005-01-07 08:51:49.000-0600

I try this patch after 01-10-05 , i have VocalTec gateway with this problem :) I now use MVTS from Mera Networks with a flag 'fake_rtcp=1' for the decision of this problem.
By: warp (warp) 2005-01-07 08:57:21.000-0600

Statistics-reporting interesting for all voip channels that using RTP/RTCP (SIP , H323 , MGCP).
By: warp (warp) 2005-01-10 04:26:10.000-0600

Please check ,this in patch:

@@ -520,7 +708,7 @@

if (!rtp->lastrxts)
rtp->lastrxts = timestamp;
-
+
if (rtp->rxseqno) {
for (x=rtp->rxseqno + 1; x < seqno; x++) {
/* Queue empty frames */
@@ -584,10 +772,10 @@

Compiller output:

rtp.c:156: warning: no previous prototype for `timeval2ntp'
rtp.c: In function `timeval2ntp':
rtp.c:158: warning: this decimal constant is unsigned only in ISO C90
rtp.c: At top level:
rtp.c:178: warning: no previous prototype for `ast_rtcp_calc_interval'
rtp.c: In function `ast_rtcp_read':
rtp.c:426: warning: `rtt' might be used uninitialized in this function
rtp.c: In function `ast_rtp_read':
rtp.c:712: error: structure has no member named `rxseqno'
rtp.c:713: error: `x' undeclared (first use in this function)
rtp.c:713: error: (Each undeclared identifier is reported only once
rtp.c:713: error: for each function it appears in.)
rtp.c:713: error: structure has no member named `rxseqno'
rtp.c:723: error: structure has no member named `rxseqno'
rtp.c: In function `ast_rtp_destroy':
rtp.c:1173: warning: unsigned int format, double arg (arg 2)
rtp.c:1174: warning: unsigned int format, double arg (arg 2)
rtp.c: In function `ast_rtcp_write_sr':
rtp.c:1341: warning: unsigned int format, __time_t arg (arg 2)
rtp.c:1341: warning: unsigned int format, long int arg (arg 3)
rtp.c: In function `ast_rtcp_write_rr':
rtp.c:1412: warning: unsigned int format, double arg (arg 2)
make: *** [rtp.o] Error 1
By: warp (warp) 2005-01-15 13:04:39.000-0600

I tested this patch with Vocaltec Gateway. All work fine. Call dont dropped after 60sek.
By: Filip Olsson (folsson) 2005-01-17 14:09:41.000-0600

What version did you apply the patch on?
By: warp (warp) 2005-01-18 08:46:12.000-0600

CVS-HEAD-11/05/04
By: stevekstevek (stevekstevek) 2005-01-19 18:51:47.000-0600

This should eventually get coordinated with bug 3236, and bug 2532.

3236 implements the basic RTCP RR stuff for IAX2. When SIP and IAX2 are bridged, the RTCP RR's should probably be bridged as well.

bug 2532 implements a jitterbuffer, which will give you proper data to make reports.
By: Filip Olsson (folsson) 2005-01-30 05:50:18.000-0600

stevekstevek: I don't think we need ASTERISK-2491 to fill those reports. Although those probably will be more accurate than the numbers we send now.
By: ianplain (ianplain) 2005-02-15 10:35:49.000-0600

Hi I have been asked by mark to wrap http://bugs.digium.com/bug_view_page.php?bug_id=0003582 into this bug report.

Basicly my problem is calls drop when users who have called via a pstn gateway and are leaving a message. Itseems to be because RTCP reports arnt sent to the gateway when callers are leaving messages.

below is a copy from the gateway supplier

"Hi Ian,

I think I know what is happening. The Cisco equipment that we use to
gateway

PSTN -> VoIP includes a timer to monitor the RTCP (RTP/audio control)
stream, and if it detects that this has been interrupted it will
disconnect the call.

The primary use of this feature is to detect VoIP endpoints which
'disappear' during a call without signalling a disconnect during the call,
and thereby preventing calls from being longer than they should be.

It would appear that during voicemail, or indeed any application which
doesnt transmit audio on a SIP call ceases RTCP transmissions at the same

time as it stops sending RTP audio. This also appears to occur when a
IAX->SIP conversion occurs within Asterisk. (In fact, I don't know what
other network resources are in use between us and your Asterisk, so it
could lie elsewhere, but I don't think so)

As a result, the gateway thinks you have disappeared and the call is disconnected.

Whilst we could cause temporary relief by extending this timer, this is
not the solution to the problem, the answer lies in ensuring that Asterisk
continues to send RTCP reports even when there is currently no media to send. "

If the patch here mentioned resolves the problem is there patch against head ?
By: Filip Olsson (folsson) 2005-02-15 11:10:41.000-0600

ianplain: Actually there isn't a patch against -HEAD at the moment(atleast not that I'm aware of). But I don't think it would be that hard to get. It's not much that has changed in rtp.c since this patch.

I'll try to find some time to get it up against -HEAD in the days to come but can't promise anything.
Isn't there anyone else out there that already have it?

If I would get it up and running on -HEAD would you help me test it? I don't have any high volume -HEAD-boxes running to try it on.
By: ianplain (ianplain) 2005-02-15 11:21:23.000-0600

Yep no problem. I will apply it and test it, I have aleady lost one order because of this problem as a customer got cut off halfway through leaving his number :-(

Cheers Ian
By: Filip Olsson (folsson) 2005-02-15 11:27:42.000-0600

ianplain: Would you like to just do a ASCII-drawing of the setup?

Is it something like: <your *>---IAX---<someones *>---SIP---<Cisco>

or is it: <your *>---SIP---<Cisco>?
By: ianplain (ianplain) 2005-02-15 11:42:27.000-0600

Hi Not sure of the exact topo but it proberly

<your *>---IAX---<someones *>---SIP---<Cisco>

and

<your *>---SIP----<someones ?>-----<Cisco>?

as the problem happens on both SIP and IAX calls
By: Olle Johansson (oej) 2005-02-15 14:11:39.000-0600

The real question seems to be if the rtcp is connected to rtp timing, which will cease transmitting if we have no incoming audio... Seems from reading the mail from the service provider that we need rtp/rtcp based on zaptel timing or some other timer than incoming stream.

I think we're moving to another timer when on hold, but I don't know the current status for normal situations. Worth investigating!
By: ianplain (ianplain) 2005-02-15 14:36:23.000-0600

Thats basicly what he has said. The call would stay up if it got an rtcp report every 5 - 10 seconds as the ciscos are set to time out at 29 seconds or so.
By: ianplain (ianplain) 2005-02-16 17:20:41.000-0600

Hi
Thanks to the work of another user who has had the same problem and has written a small hack that transmits a "hiss" every 20 seconds The imediate problem is resolved, The RTCP issue does need to be sorted so I am happy to try a patch if one is done aginst head. If anyone wants he Hack let me know.
By: Filip Olsson (folsson) 2005-02-17 03:56:10.000-0600

oej: concerning your question about RTP timing. The sending of RTCP-packets is scheduled with ast_sched_add().

My question about the topo is if the Asterisk is closest to the 'thing' that drops the call? A thing about this patch is that it won't send RTCP unless it receives some RTCP-packet.
By: drmac (drmac) 2005-02-17 16:37:03.000-0600

Will this patch help fix these messages:

Feb 15 14:08:13 NOTICE[5434]: rtp.c:505 ast_rtp_read: Unknown RTP codec 72 received

(using XTen Pro btw)
By: Filip Olsson (folsson) 2005-02-17 16:58:26.000-0600

drmac: Nope, it won't.
By: warp (warp) 2005-02-28 07:41:44.000-0600

RTCP on IAX2 its great, but what do if call go from SIP to SIP or H323 to H323 or SIP to H323?
By: Paul Cadach (pcadach) 2005-02-28 08:43:29.000-0600

Warp_: IAX2 isn't uses RTP/RTCP for audio/video packets. RTP/RTCP is for H.323/SIP/Skinny/MGCP/etc.
By: Brian West (bkw918) 2005-03-17 21:15:09.000-0600

Can you update this to latest CVS-head please.

/b
By: alex (alex) 2005-03-22 06:48:55.000-0600

Ye, plz update this patch to 1.07
By: John Todd (jtodd) 2005-04-27 11:58:43

I'd be happy to test this against -HEAD if it can be made to compile. I have Cisco, Grandstream, Xten, Nextone, and others in both gateway and client configurations.
By: Filip Olsson (folsson) 2005-05-04 10:02:52

I'm working on updating the stuff to -HEAD now, hang in there and I'll post an updated patch when it's done.
By: Filip Olsson (folsson) 2005-05-07 19:55:47

There you go. A patch against -HEAD. Haven't had all that much testing.
By: John Todd (jtodd) 2005-05-08 19:32:30

A few notes:

1) Need to squash the output on this line in the patch down to a more reasonable verbose level - it fills up my display on any calls. I just commented it out for testing purposes.
ast_verbose("SEQNO cycled: %u\t%d\n", rtp->cycles, seqno);

2) I have a 7960 (which has RTCP) located on 10.0.1.2, which can "directly" see my Asterisk box (no NAT, so I'm getting the right IP address.) I use "rtcp debug ip 10.0.1.2" but I see no output on the debug line. If I turn on "rtcp debug" then I see the debugging from calls on 10.0.1.2

3) When I turn on "rtcp debug" I get this output after a short (3 second?) call to voicemail with a bit of audio in each direction:

ms1*CLI>
RTP-stats
Our Receiver:
SSRC: 870534184
Received packets: 0
Lost packets: 0
Jitter: 3339348296
Transit: 1073741824
RR-count: 0
Our Sender:
SSRC: 880214629
Sent packets: 0
Lost packets: 0
Jitter: 0

RTT: 0.000000

RTP-stats
Our Receiver:
SSRC: 0
Received packets: 0
Lost packets: 0
Jitter: 0
Transit: 0
RR-count: 0
Our Sender:
SSRC: 115831144
Sent packets: 0
Lost packets: 0
Jitter: 0

RTT: 0.000000
ms1*CLI>

....not quite sure what that all means, and it looks like perhaps there is double-counting here?

4) Does this patch rely on NTP time being accurate? How accurate?

5) Interestingly, I see only Asterisk sending RTCP Sender Reports to the UA, and not the other way around. This is true for both Polycom IP600 and Cisco 7960.

6) I get some compile warnings - not sure if they're important, but I know that everyone is trying to clean up the noise during the compile:

gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i686 -DZAPTEL_OPTIMIZATIONS -DASTERISK_VERSION=\"CVS-HEAD-05/08/05-23:29:27\" -DASTERISK_VERSION_NUM=999999 -DINSTALL_PREFIX=\"\" -DASTETCDIR=\"/etc/asterisk\" -DASTLIBDIR=\"/usr/lib/asterisk\" -DASTVARLIBDIR=\"/var/lib/asterisk\" -DASTVARRUNDIR=\"/var/run\" -DASTSPOOLDIR=\"/var/spool/asterisk\" -DASTLOGDIR=\"/var/log/asterisk\" -DASTCONFPATH=\"/etc/asterisk/asterisk.conf\" -DASTMODDIR=\"/usr/lib/asterisk/modules\" -DASTAGIDIR=\"/var/lib/asterisk/agi-bin\" -DBUSYDETECT_MARTIN -fomit-frame-pointer -c -o rtp.o rtp.c
rtp.c:162: warning: no previous prototype for `timeval2ntp'
rtp.c: In function `timeval2ntp':
rtp.c:164: warning: decimal constant is so large that it is unsigned
rtp.c: At top level:
rtp.c:184: warning: no previous prototype for `ast_rtcp_calc_interval'
rtp.c: In function `ast_rtcp_read':
rtp.c:443: warning: `rtt' might be used uninitialized in this function
rtp.c: In function `ast_rtp_read':
rtp.c:607: warning: `tseqno' might be used uninitialized in this function
rtp.c: In function `ast_rtp_destroy':
rtp.c:1284: warning: unsigned int format, double arg (arg 2)
rtp.c:1285: warning: unsigned int format, double arg (arg 2)
rtp.c: In function `ast_rtcp_write_sr':
rtp.c:1453: warning: unsigned int format, __time_t arg (arg 2)
rtp.c:1453: warning: unsigned int format, long int arg (arg 3)
rtp.c: In function `ast_rtcp_write_rr':
rtp.c:1524: warning: unsigned int format, double arg (arg 2)

7) Here's a sample of the output during a Sender Report transmission as pushed to the CLI:

ms1*CLI>
Sending RTCP RR to 10.0.1.2:24275
Our SSRC: 1900566630
Their SSRC: 870534184
Fraction lost: 256
Cumulative loss: 81986787
IA jitter: 2872377979
Their last SR: 0
DLSR: 65520.2130 (sec)

Kind of wacky numbers. Not sure what they mean, again, but err... I think something is amiss there.

8) The patch to get some of this information as Dialplan variables would be lovely. They can be put into CDR details (as part of the user-definable record indicator) or printed or... other stuff. Ideally, I'd like to get the stats into the SIP BYE message, since SIP is a common user of RTP, and reporting RTP (or media in general) stats through the SIP signalling path at the end of the call is becoming more useful the more I think about it.
By: Filip Olsson (folsson) 2005-05-09 12:13:16

jtodd: Fixed a couple of your problems. I would think that the strange numbers would go away now.
By: Filip Olsson (folsson) 2005-05-09 12:15:06

Concerning RTP-stats in the BYE, why would you want that information in the BYE? Wouldn't you rather have it in the usefield(only)?
By: Filip Olsson (folsson) 2005-05-23 11:49:09

I took the time to update this patch to -HEAD as everyone told me... It seems that jtodd was the only one interested after all.

Did it work?

The stuff jtodd reported has been fixed in rtcp_path_20050509.diff.text.
By: Dean Whitlock (webjester) 2005-06-11 12:14:43

I am having the same issues here as ianplain is this a fix ?
By: Filip Olsson (folsson) 2005-06-15 15:25:48

Webjester: Really don't know, never quite understood his setup and he never told us how(if?) he solved it by applying this patch.
By: drmac (drmac) 2005-06-15 15:55:16

got a few failures patching most recent CVS. Fixed by hand. Got this when compiling:

rtp.c:160: warning: no previous prototype for `timeval2ntp'
rtp.c: In function `timeval2ntp':
rtp.c:162: warning: decimal constant is so large that it is unsigned
rtp.c: At top level:
rtp.c:197: warning: no previous prototype for `ast_rtcp_calc_interval'
rtp.c:563: warning: no previous prototype for `ast_rtcp_write_rr'
rtp.c:1270: warning: no previous prototype for `ast_rtp_get_quality'
rtp.c:1430: warning: no previous prototype for `ast_rtcp_write_sr'

(edited**)

doh..forgot to patch rtp.h too. But it was also missing some prototypes. The only error I get now is the decimal contsant too large thing.

By: sengland (sengland) 2005-06-15 16:44:56

folsson,

The issue I am facing is that when callers connect to me via what I think are cisco pstn gateways and attempt the leave a voicemail they can not leave a message longer then about 35 seconds. This also happens when I am using the "record" or "monitor" app. However if the callers connect to me via my own T1's connected to an asterisk server with a digium card in it they do not get disconnected (The Digium card is in a seperate server connecting to my voicemail server via IAX), they can leave a message for as long as they desire. They also do not get disconnected if they are calling a number provided by Voicepulse. The disconnect happens if they are connected via IAX or SIP.

I applied the patch and appear to get the stats during debug (Only under SIP, nothing when I am using an IAX connection) however I still get disconnected with this patch applied. I was hoping that this patch addresses this issue or I could get a copy of the patch mentioned by ianplain that someone had hacked together to send hiss every 20 seconds.

I am wondering if this patch is intended to fix this issue or am I off track here?
By: Filip Olsson (folsson) 2005-06-16 15:52:13

sengland: IAX don't use RTP that's the reason you don't get the stats on those channels. Can't you get some kind of log from those Cisco gateways?

It seems that you have a different problem than those that have solved their problem by applying this patch. Some gateways disconnect calls after a while when they don't receive any RTCP, that's one of the problems this patch fixes.
By: drmac (drmac) 2005-06-16 17:21:02

is there some explanition of what all the rtcp debug stuff means?
By: Filip Olsson (folsson) 2005-06-21 09:34:08

drmac: The best thing would be to read the RFC for RTP and RTCP on http://www.faqs.org/rfcs/rfc3550.html. Section 6.4.1 and 6.4.2 covers what all that stuff means, the output of the debug is more or less the stuff that's coming on the wiring(or going out on it).
By: drmac (drmac) 2005-06-22 16:07:10

Sending RTCP RR to 205.158.247.204:20081
Our SSRC: 1825897944
Their SSRC: 0
Fraction lost: 0
Cumulative loss: 4294966990
IA jitter: 0.0003
Their last SR: 0
DLSR: 65522.1050 (sec)

No matter who I call, when I call, or whatever, "Cumlative loss:", "Their SSRC", "Fraction lost" and "Their last SR" are always the numbers you see above; 0.

"Our SSRC" changes with each call and remains constant thru the call.

This is more of an "here's a real world example" post. I don't know if any of it is right or wrong. But I'm sure that decimal constant error in posting 0029003 could be a problem.
By: Michael Jerris (mikej) 2005-07-12 19:29:22

What is this waiting for? Is this code tested and ready for some code review or are you still working out the bugs?
By: drmac (drmac) 2005-07-12 20:06:52

just tried to apply to recent cvs checkout and got several hunk failed notices. I'm trying to clean those up now.
By: drmac (drmac) 2005-07-12 21:06:11

ok..the two i just upped should patch against most recent cvs..(kevin "had' to make an update to rtp.c right before i was going to upload these.)

everything compiles fine here except the following:

rtp.c: In function `timeval2ntp':
rtp.c:163: warning: decimal constant is so large that it is unsigned
By: Michael Jerris (mikej) 2005-07-20 18:40:52

Is this up to date with current head? Where do we stand on this?
By: drmac (drmac) 2005-07-20 20:42:18

it is up to date but read my previous post about integer too large. i have no clue how to fix that. a better C programmer than I will have to look at it.
By: drmac (drmac) 2005-07-21 13:42:53

crap..not up to date..give me a min to bring them up to date with current cvs
By: drmac (drmac) 2005-07-21 14:41:44

rtcp.patch.txt will patch both rtp.c and rtp.h and should be current with most recent CVS.

These are old ones of mine and can be deleted:
rtpc_rtp.c.patch.txt
rtpc_rtp.h.patch.txt
By: Filip Olsson (folsson) 2005-07-28 05:26:22

drmac: How's it working for you? Do you have it in production?
I haven't worked on this since my last update to HEAD for this patch.
We use this in production and have done so for quite some time now, works like a charm.
By: Olle Johansson (oej) 2005-07-28 05:43:10

folsson: Can we move this from experimental features and make it ready for CVS?
By: drmac (drmac) 2005-07-28 08:57:13

I don't use it in production for 2 reasons:

1. the unsigned int warning
2. I honestly have no idea "how" to properly use it. There some way I can collect the stats for graphing? or something?
By: Filip Olsson (folsson) 2005-08-01 10:54:31

oej: Fine with me. Have you tried it? I'm not sure it has enough of testing, although that would be resolved if it went into CVS...

drmac: I use a function in chan_sip to grab the information collected and put that in the userfield of the CDR. You could use that information for graphing but not 'within' a call, but rather over a bunch of calls. Something like 'average IAJ for last 1000 calls', you can't use it to detect that there is a huge amount of jitter 10 seconds into a specific call. The data you get is something like number of lost packets, average jitter, round-trip-time and the SSRC's of the peers.
By: drmac (drmac) 2005-08-01 11:14:35

folsson,
could you provide more info on that? Perhaps on a wiki when this goes into 1.2? I think many people (including myself) would love to be able to do that too. Or contact me off-list and maby I can throw something together. (mboehm@cytelcom.com) thanks.
By: linuss (linuss) 2005-08-01 13:15:10

Is there any real reason why this can't enter CVS? We have literally hundreds of clients using SIP & Asterisk who have problems with this issue! (lack of RTCP reports being *sent* from Asterisk)
By: Tilghman Lesher (tilghman) 2005-08-01 15:17:49

linuss: please apply the patch, test it, and give us feedback on how well it works.
By: Olle Johansson (oej) 2005-08-02 04:16:57

We need more test results, so we can move this from experimental to a real patch for 1.2 quickly then. And folsson, please consider uploading that chan_sip patch as well.

Write a message to asterisk-users explaining the patch and ask for testing.
By: linuss (linuss) 2005-08-02 04:26:52

I'd love to be able to apply the patch and give results, but our configuration isnt affected by this - we're sending SIP traffic direct to our customers from Cisco equipment, and I'm not going to tell them to use a patch/feature that isnt in CVS because the maintenance burden of such a configuration is too high.

However, if anyone here who has the patch applied would like to test against our gateways, feel free to drop me an email at linus@magrathea-telecom.co.uk

Linus
By: Filip Olsson (folsson) 2005-08-02 07:45:27

Just posted the very small patch for chan_sip to set the userfield in the CDR to the quality params generated by the RTCP-patch.

You have to have RTCP-patch applied to use this function.
By: Olle Johansson (oej) 2005-08-02 08:22:12

Thanks, folsson, that was easy enough.

I propose that we set a channel variable with this data, to let the user decide what to do with it in the dial plan. He might already have something important in the user field...

We might investigate adding a header on the bye or 200OK to bye with this data.
By: Filip Olsson (folsson) 2005-08-02 08:27:29

The variable sounds like a good idea.

Obviously it's not a final solution to put the data in the userfield, at least not the way it's done now. It should at least be an option, might not even be that since you can get the same result by reading the channel var and put that in the userfield 'by hand'.

jtodd suggested the thing with the BYE/200 to be done the same way as the 7940/7960's can do.
By: Tim Robbins (tim) 2005-08-03 00:38:16

I get the following error on FreeBSD 6.0-BETA:
RTCP RR transmission error: Address family not supported by protocol family

It would appear to be because rtp->rtcp->them.sin_family is not initialized before it is passed to sendto() in ast_rtcp_write_rr(). Perhaps it should be set to AF_INET in ast_rtcp_new().
By: Tim Robbins (tim) 2005-08-03 01:37:02

It also looks like the length field of Receiver Report packets is being set incorrectly. AFAIK it should be 1 + 6 * the number of report blocks that follow.
By: Filip Olsson (folsson) 2005-08-17 06:30:15

Just uploaded a new patch with tim's points corrected.
I haven't actually compiled it on FreeBSD but I think I fixed the initialization.

The point about the length-field in the RR's header has been corrected too, probably just copied the one from the SR. The length should be (2-1) + 6*number of report blocks.
By: drmac (drmac) 2005-08-17 09:31:13

just uploaded 'rtcp_patch_20050817B.patch.txt' which patches cleanly against today's CVS.

only compile errors on gcc-4 is:

rtp.c: In function ‘timeval2ntp’:
rtp.c:165: warning: this decimal constant is unsigned only in ISO C90
rtp.c: At top level:
rtp.c:1220: warning: ‘ast_rtp_get_quality’ defined but not used
rtp.c:1377: warning: ‘ast_rtcp_write_sr’ defined but not used
By: delvar (delvar) 2005-08-23 08:46:24

hi iv got the latest patch, had some problems.
first i got an UNDEFINED symbol 'ast_rtp_get_quality' in chan_sip.c when trying to load the module, i jsut commented that bit of the code out and it now loads ok.

after a bit of testing i found the call is still being dropped after the timeout.
after some investigation i found when in a call to voicemail i see the RTCP packets being sent on time but they appear to be sent to the wrong port, i did an ethreal trace and i saw the first part of the call (voicemail anouncement) was uing port 14108 on the far end but during the recording part of the voicemail the RTCP packets were being sent to 14109.. is this correct?
By: Michael Jerris (mikej) 2005-08-29 20:58:13

feature patches need to stay active to stay open. Suspending pending resolution or response to Delvar's issues. Please re-open when ready.

By: Brian West (bkw918) 2005-08-31 10:50:57

As per request.
By: delvar (delvar) 2005-08-31 10:59:46

thanks bkw,

my last post was in error, i did not understand the differance between RTP and RTCP it IS suposed to use the otehr port... may bad.

i have tested this with linuss stuff and it seems to work ok, we will be trying this on one of our main servers to see if it solves the problem and how it handls greater load and interaction with useragents.

there is still that problem with chan_sip.c with the unknown function (maybe i apply the patch wrong) i left it commented out for now.

thnaks.
By: Michael Jerris (mikej) 2005-09-02 19:08:11

Is this ready to go in for 1.2 or are there still outstanding issues?
By: Michael Jerris (mikej) 2005-09-06 17:51:14

no one has responded so I am going to assume that this is still in development and mark this post 1.2. If that is incorrect, please comment and let me know.
By: delvar (delvar) 2005-09-09 12:00:37

i am reporting a bug.. a real one i hope...
when this patch is placed on one of a hosted PBX's TRCP trafic seems to be being sent to the internal ip address of the phone. i am using nat=yes and canreinvite=no in sip.conf and the phone is behind a NAT router.

maybe you should make rtcp optional per user account? or just refuse to send RTCP to phones where the RTP ip address doesnt match?.
or not send RTCP to phones with nat=yes.
or wait till you recive an RTCP packet from the client and use that ip/port to send RTCP to.
or dont send RTCP where user=phones?
im no expert so you should be able to come up with something.

Sending RTCP RR to 192.168.254.12:10811
Our SSRC: 1761830439
Their SSRC: 1314617349
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0001
Their last SR: 0
DLSR: 65525.2240 (sec)
By: Carlos Antunes (cmantunes) 2005-09-12 23:14:42

folsson: nice patch. I applied it to CVS HEAD without a hitch. The only thing one needs to do, to avoid a compiler warning, is to replace "(unsigned int)2208988800" with the literal "2208988800u" in the timeval2ntp function.

In the same timeval2ntp function, is the calc of frac from usec supposed to be precise or approximate?

Also, what is the purpose of the unused function ast_rtp_get_quality?

By: Filip Olsson (folsson) 2005-09-13 04:05:08

Just uploaded a new patch against HEAD with cmantunes comment about the compiler warning fixed.

cmantune: concerning ast_rtp_get_quality, try the patch in rtcp_chan_sip.patch. It puts some of the information concerning losts packets and jitter into the userfield of a CDR upon hangup.

Concerning timeval2ntp, I actually don't know why the row that calculates the fraction isn't saying 3600 instead of 3650. One would think that the conversion should be exact, or at least as exact it can be.
By: delvar (delvar) 2005-09-13 04:43:09

folsson, can you look a tthe problems i pointed out above?
its --update-- NOT --update-- a big deal but would be nice ifit was a little smarter.

other than that this is working prety well.

woops, i should learn to type :)

By: Carlos Antunes (cmantunes) 2005-09-13 11:04:42

folsson: applied the patch rtcp_chan_sip.patch without problems. Got this warning, though:

chan_sip.c: In function `sip_hangup':
chan_sip.c:2336: warning: implicit declaration of function `ast_rtp_get_quality'
chan_sip.c:2336: warning: assignment makes pointer from integer without a cast

Maybe you need to add ast_rtp_get_quality declaration to rtp.h?

EDIT: WHOOPS! Just saw this patch exists. Is it possible to create one patch file for all the changes instead of 3?

Also, I'll look at the formula to calc frac from usec to see if I understand the reason for those constants. Where did you get the formula from, if you don't mind my asking?

By: Filip Olsson (folsson) 2005-09-13 11:18:17

cmantunes: yes the declaration of ast_rtp_get_quality should be put into rtp.

Concerning those constants, the only constant I see is 2208988800 and that's the number of seconds between 1900 and 1970(but you knew that).
The bitshifting is something like the one found at http://vic2.nchc.org.tw/lxr/http/source/ntp-time.h?c=rtp.

delvar: We don't send RTCP to the peer unless we get something from him first. We send to the address that sent to us.

Have anyone else experienced the same problem as delvar?
By: delvar (delvar) 2005-09-15 11:34:23

hi, folsson, i am using a snom behind nat (if that makes any differance).
looking at the CLI i do not see a recived RTCP packet only sent ones, and they are still to teh internal ip address, i can try using another phone if you want.

when dialing though a gateway i can see the sent and recived TRCP packets just fine.

can you add a sipmle 'sendrtcp=yes/no' to sip.conf per entity?

i have got latest CVS, and applied teh patches,
rtp_h_path_20050508.diff.text
rtcp_patch_20050913.patch.txt

the did a make clean %% make isntall

is there anything i can do to help resolve this?
By: delvar (delvar) 2005-09-15 11:39:23

this is what i see when i dial out from the snom to the gateway,

Got RTCP from 213.166.5.134:17163
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 2248475680
NTP timestamp: 3335791065.2484215808
RTP timestamp: 0
SPC: 3791 SOC: 606560

Sending RTCP RR to 192.168.254.12:10319
Our SSRC: 23377201
Their SSRC: 1693300334
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0000
Their last SR: 0
DLSR: 14.0020 (sec)

Sending RTCP RR to 213.166.5.134:17163
Our SSRC: 2093271699
Their SSRC: 537134470
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0013
Their last SR: 567869440
DLSR: 4.1770 (sec)
By: linuss (linuss) 2005-10-03 06:05:00

Please please please can any,all of you involved in this particular bug/patch please do whatever is required to get this into 1.2, whilst not directly affecting any of our internal configurations, does cause a number of support calls from Asterisk using clients who complain of dropped voicemail calls etc.

Surely it can't be that hard for Asterisk to get one of the basic RTP features working!

Linus
By: Olle Johansson (oej) 2005-10-05 09:54:42

I am removing the "post 1-2" tag, since this patch has been in the tracker since long time before freeze, it's tested and confirmed by many users and ready to meet the cruel world of CVS head.

Now it's up to Kevin and Mark whether or not this will happen, but I do vote for it and take the risk to recommend inclusion in CVS.
By: paul miller (idkpmiller) 2005-10-12 06:20:49

if there is a nat between asterisk and the endpoint the two things may occur.
1. the RTCP stream may not follow the standard and be provided to asterisk on the odd port number as in RTP +1
2. if asterisk is behing nat then the incoming RTCP from the remote endpoint will not pass through the NAT, asterisk would need to send a RTCP packet to open a port through the local NAT device.

thats my understanding of RTCP and NAT
By: paul miller (idkpmiller) 2005-10-12 06:21:33

has this gone into CVS head yet?
By: Filip Olsson (folsson) 2005-10-12 06:36:17

idkpmiller: The problem with Asterisk behind a NAT and this patch is that we won't send RTCP unless the other end has sent some to us first(see previous posts), and since we won't get the incoming RTCP because of the NAT... catch 22.

No, this patch hasn't went into CVS. Still waiting for someone(kpfleming?) to tell me what to do to make that happen.
By: Olle Johansson (oej) 2005-10-18 12:20:16

Assigned to kpfleming for review.
By: Olle Johansson (oej) 2005-10-18 12:22:34

folsson: Which files are needed for this patch? Can you please make *one* patch file, so I can remove the old files?
By: Filip Olsson (folsson) 2005-10-18 12:27:10

I don't think this patches cleanly with HEAD at the moment. I'll update it and add it as one patch soon.
By: paul miller (idkpmiller) 2005-10-19 05:24:01

@folsson,
Ok a silly question why does this patch not send an RTCP packet without having received one first? The idea of Send RTCP = yes in a config file seems reasonable to me.
The first priority to me is to get the patch in HEAD and then add unprompted sending capabilty as a later update.
By: Filip Olsson (folsson) 2005-10-19 06:01:23

Just uploaded rtcp_patch_20051019.patch that should patch cleanly with -HEAD, that's the only patch one needs to get it up, it includes both rtp.h and rtp.c.

idkpmiller: I think we should add an option in rtp.conf to toggle RTCP. The idea of sending RTCP only when we get some seemed like a good idea at the time... not so very much now though.
By: Filip Olsson (folsson) 2005-10-19 06:03:37

Could someone with access remove all patches except rtcp_patch_20051019.patch and rtcp_chan_sip.patch?

Note: you don't need rtcp_chan_sip.patch for this thing to work, it's just there to put some data in the userfield of the CDR.
By: Olle Johansson (oej) 2005-10-19 08:00:37

Hmmm. It tries to send RTCP to my NAT address, not the same as RTP is sent to.

Folsson: Contact me on IRC; have a few other ideas.
By: Olle Johansson (oej) 2005-10-19 08:52:16

Uploaded patch with small formatting changes.

Suggestions:
* Change NAT so we depend on first incoming RTP packet
* Change "RTCP debug" to "RTP RTCP debug"
* Fixes problems with scheduler
By: Olle Johansson (oej) 2005-10-19 09:16:51

Disclaimer on file as usual. Folsson will clean up my patch and fix some outstanding issues.
By: Serge Vecher (serge-v) 2005-10-19 13:03:05

Given this is tagged as "Experimental Features" with warnings not to try it in the office -- is this patch safe to test in production environment. If so, what benefits/behavior changes to expect for those of us not familiar with RTCP. Thanks!
By: Olle Johansson (oej) 2005-10-19 13:34:12

This is moving towards production ready software quickly. At this point I don't see it as a big risk using it on your system.
By: Serge Vecher (serge-v) 2005-10-19 13:43:22

Olle:

Great! What about the benefits: what should we expect to improve/change after applying this patch?

By: Filip Olsson (folsson) 2005-10-19 19:34:04

vechers: We would love if you tried the patch, but if you don't have any problems with dropped calls because of the lack of RTCP this won't do you much good.

oej: Sorry for not getting the patch ready tonight, I'll try to fix it tomorrow.
By: John Martin (jfp_martin) 2005-10-20 14:47:58

Hi Everyone,
I've tried the latest 19/10 patch on our dev box against our videophones running SIP. I can see RR's being sent in both directions but the Asterisk box isn't sending out SR's for any of the media streams. This seems to be the case for non-NAT as well as NAT'ed calls. "rtcp debug on" doesn't really give me any indication of the source of the problem either other than all outbound packet and octet counts are zero.
I have an Ethereal trace showing this if any of the developers are interested in having a look.

Perhaps I can also say that any RTCP support put into the 1.2 release will be better than nothing, video over IP has real problems if there's no feedback on available bandwidth.

regards, John

By: John Martin (jfp_martin) 2005-10-21 03:04:20

Further to my post of last night here's a rtcp debug trace of what's happening. If anyone wants to look into this then I'd be more than happy to detail what's going on in an email...

The trace below is of a video call between a public (non-NAT'd) phone and a private IP address phone with Asterisk proxying. Looks like Asterisk doesn't know about the SDES rtcp packet, maybe that's causing problems??

(Sorry for filling up the bug report with a lot of trace but I think the history of RTCP packets in and out may be important)

Got RTCP from 10.1.7.25:5001
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 2198008845
NTP timestamp: 3338869809.4191698944
RTP timestamp: 701087115
SPC: 60 SOC: 29520

Got RTCP from aaa.bbb.ccc.ddd:5001
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 1574963750
NTP timestamp: 4145017055.4053401600
RTP timestamp: 356398092
SPC: 61 SOC: 30012

Got RTCP from 10.1.7.25:5003
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 4089884951
NTP timestamp: 3338869810.3848077312
RTP timestamp: 3600881361
SPC: 31 SOC: 40420

Got RTCP from aaa.bbb.ccc.ddd:5003
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 2107990821
NTP timestamp: 4145017056.3125653504
RTP timestamp: 4013905734
SPC: 31 SOC: 38795

Sending RTCP RR to 10.1.7.25:5001
Our SSRC: 1013500637
Their SSRC: 234095235
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0046
Their last SR: 472973312
DLSR: 1.3560 (sec)

Sending RTCP RR to aaa.bbb.ccc.ddd:5001
Our SSRC: 1279812537
Their SSRC: 638247005
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0423
Their last SR: 4041146368
DLSR: 1.3780 (sec)

Got RTCP from 10.1.7.25:5001
PT: 201(Receiver Report)
Reception reports: 1
SSRC of sender: 3721029692
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 16635
Sequence number cycles: 0
Interarrival jitter: 199
Last SR(our NTP): 0.0000000000
DLSR: 0.0000 (sec)

Got RTCP from aaa.bbb.ccc.ddd:5001
PT: 201(Receiver Report)
Reception reports: 1
SSRC of sender: 3110291532
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 63916
Sequence number cycles: 0
Interarrival jitter: 192
Last SR(our NTP): 0.0000000000
DLSR: 0.0000 (sec)

Sending RTCP RR to 10.1.7.25:5003
Our SSRC: 1440151241
Their SSRC: 397526771
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0000
Their last SR: 473038848
DLSR: 1.9410 (sec)

Sending RTCP RR to aaa.bbb.ccc.ddd:5003
Our SSRC: 2041206544
Their SSRC: 627287421
Fraction lost: 0
Cumulative loss: 0
IA jitter: 0.0000
Their last SR: 4041211904
DLSR: 1.9000 (sec)

Got RTCP from 10.1.7.25:5003
PT: 201(Receiver Report)
Reception reports: 1
SSRC of sender: 3388397141
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 35029
Sequence number cycles: 0
Interarrival jitter: 2165
Last SR(our NTP): 0.0000000000
DLSR: 0.0000 (sec)

Got RTCP from aaa.bbb.ccc.ddd:5003
PT: 201(Receiver Report)
Reception reports: 1
SSRC of sender: 274180729
Fraction lost: 0
Packets lost so far: 0
Highest sequence number: 39000
Sequence number cycles: 0
Interarrival jitter: 783
Last SR(our NTP): 0.0000000000
DLSR: 0.0000 (sec)

Got RTCP from 10.1.7.25:5001
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 2198008845
NTP timestamp: 3338869813.0996139008
RTP timestamp: 701119794
SPC: 119 SOC: 58548

Got RTCP from aaa.bbb.ccc.ddd:5001
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 1574963750
NTP timestamp: 4145017060.1133830144
RTP timestamp: 356431442
SPC: 130 SOC: 63960

Got RTCP from 10.1.7.25:5003
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 4089884951
NTP timestamp: 3338869814.3298222080
RTP timestamp: 3601249078
SPC: 115 SOC: 134222

Got RTCP from aaa.bbb.ccc.ddd:5003
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 2107990821
NTP timestamp: 4145017061.1786650624
RTP timestamp: 4014279870
SPC: 113 SOC: 122708

RTP-stats
Our Receiver:
SSRC: 638247005
Received packets: 152
Lost packets: 0
Jitter: 0.0281
Transit: 0.1993
RR-count: 1
Our Sender:
SSRC: 1279812537
Sent packets: 0
Lost packets: 0
Jitter: 192

RTT: 0.000000

RTP-stats
Our Receiver:
SSRC: 627287421
Received packets: 119
Lost packets: 0
Jitter: 0.0000
Transit: 0.0000
RR-count: 1
Our Sender:
SSRC: 2041206544
Sent packets: 0
Lost packets: 0
Jitter: 783

RTT: 0.000000

RTP-stats
Our Receiver:
SSRC: 234095235
Received packets: 145
Lost packets: 0
Jitter: 0.0100
Transit: 0.0037
RR-count: 1
Our Sender:
SSRC: 1013500637
Sent packets: 0
Lost packets: 0
Jitter: 199

RTT: 0.000000

RTP-stats
Our Receiver:
SSRC: 397526771
Received packets: 136
Lost packets: 0
Jitter: 0.0000
Transit: 0.0000
RR-count: 1
Our Sender:
SSRC: 1440151241
Sent packets: 0
Lost packets: 0
Jitter: 2165

RTT: 0.000000
By: Justin Unger (justinu) 2005-10-23 19:42:40

Found a bug after patching rtp.c on a PPC MacOS X box.

It appears that rtp->rtcp->them.sin_family isn't being set properly, and any attempts to send the RTCP datagrams fail with an error from sendto(): "Address family not supported by protocol family".

I was able to solve this problem by setting rtp->rtcp->them.sin_family = AF_INET, just before the sendto() is called in ast_rtcp_write_rr().
By: Justin Unger (justinu) 2005-10-23 19:47:49

After applying this patch, I noticed that asterisk only sends RTCP Receiver Reports (Packet Type=201).

RFC3550 says that you should send Sender Reports (Packet Type=200), if you are sending any RTP packets. RR should only be used if you're receiving and not sending any packets.

Curiously enough, there is a function in the patch to generate a partial SR packet, but it's never called in the code. The decoding of SR packets is also incomplete, as they contain a receiver report inside of them, which is not parsed in ast_rtcp_read().

I'm working on solving these issues if anyone is interested.
By: Filip Olsson (folsson) 2005-10-26 17:55:23

justinu pointed out that we never actually call ast_rtcp_write_sr from rtp.c. That 'feature' disappeared between some of the patches, but is now back. That would explain that some of you guys have mentioned strange stats.

justinu also pointed out that the SR missed a report block for our receiver.

Fixed a missing AF_INET for BSD/OSX.

Directly when we receive our first RTP packet we also schedule the sending of a RR, we did that before too but we didn't set the address upon receiving the packet so ast_rtcp_write_rr would return directly. That's fixed now, that means we will always send RTCP (if we atleast got some RTP). Before this change two Asterisks wouldn't send RTCP between each other since no one started the other.

The CLI commands are now named 'rtp rtcp debug [ip[:port]]' and 'rtp rtcp no debug' per oej's recommendation.

justinu: don't forget to post that libpcap-dump with the stuff from Level3.
By: Filip Olsson (folsson) 2005-10-27 08:12:14

I have noticed some strange behaviour with this patch. Mixed up rtcp->sr_schedid and rtcp->rr_schedid in some places... An updated patch will be available shortly.
By: Filip Olsson (folsson) 2005-10-27 08:31:14

Use rtcp_patch_200510271516.patch.txt instead of anything else, fixed the problems with the scheduler.

Could someone with the right rights remove everything except rtcp_patch_200510271516.patch.txt and rtcp_chan_sip.patch?
By: Paul Cadach (pcadach) 2005-10-27 08:54:12

Outdated attachments is deleted as requested.
By: paul miller (idkpmiller) 2005-10-28 02:50:21

Could someone explain how a noobie can apply the patch, I would really like to test this but have never patched a file before.

thanks
By: Serge Vecher (serge-v) 2005-10-28 09:06:41

idkpmiller:

1) cd /usr/src/asterisk
2) patch -p0 < rtcp_patch_200510271516.patch.txt

you may have to supply relative paths to rtp.c -- always inspect the patch to see what's affected. Also, please, please, please, do a little research before asking a trivial question. This was answered more times than how to produce a backtrace. Thanks! Ejoy the testing and please post the results back.
By: paul miller (idkpmiller) 2005-10-28 16:25:45

Verchers

Thanks for you help I was doing it correct, but as I noob I couldnt be certain, ok the patch installed fine on CVS Head but when I do a make clean; make install i get the following errors:

rtp.c:193: warning: no previous prototype for `timeval2ntp'
rtp.c:215: warning: no previous prototype for `ast_rtcp_calc_interval'
rtp.c: In function `ast_rtp_read':
rtp.c:711: `ast_rtcp_write_rr' undeclared (first use in this function)
rtp.c:711: (Each undeclared identifier is reported only once
rtp.c:711: for each function it appears in.)
rtp.c: At top level:
rtp.c:1291: warning: no previous prototype for `ast_rtp_get_quality'
rtp.c:1452: warning: no previous prototype for `ast_rtcp_write_sr'
rtp.c:1544: warning: no previous prototype for `ast_rtcp_write_rr'
rtp.c:1544: `ast_rtcp_write_rr' used prior to declaration
make: *** [rtp.o] Error 1

have I done something wrong or is there an issue with the patch rtp.c code?

anyone else getting this?
By: Josh (jmcadam) 2005-10-29 03:28:40

I used the patch uploaded on 27/10/05 using cvs head from same day and keep getting segfaults right after attempt to delete non existent schedule entry XXX when a call is hungup - other than that it was working ok and generating stats.

Also that patch seems to be missing the changes for rtp.h

Backtrace showed that the send SR function was being called and causing segfault. I can't attach backtrace at the moment but if you guys need it i'll add it after the weekend

By: delvar (delvar) 2005-11-01 04:21:45.000-0600

iv not had time to test the latest patch but the previus version worked like a charm, any chance we can get these problems sorted and get it into cvs?
By: Sergey Basmanov (sb) 2005-11-07 04:11:16.000-0600

Summary:
RTP-stats
* Our Receiver:
SSRC: 277442626
Received packets: 1347
Lost packets: 4294953145
Jitter: 0.0182
Transit: -0.0103
RR-count: 6
* Our Sender:
SSRC: 976030384
Sent packets: 1653
Lost packets: 27
Jitter: 0

RTT: 0.654035

And one of packets:

Got RTCP from 80.68.242.145:26555
PT: 200(Sender Report)
Reception reports: 1
SSRC of sender: 1114650374
NTP timestamp: 3340345702.2997547008
RTP timestamp: 0
SPC: 381 SOC: 7620
Sent RTCP SR to 80.68.242.145:26555
Our SSRC: 976030384
Sent(NTP): 1131356902.3202191360
Sent(RTP): 240160
Sent packets: 1501
Sent octets: 30020
Report block:
Fraction lost: 87
Cumulative loss: 4294953145
IA jitter: 0.0152
Their last SR: 2707816448
DLSR: 0.7320 (sec)

Sending RTCP RR to 80.68.242.145:26555
Our SSRC: 976030384
Their SSRC: 277442626
Fraction lost: 0
Cumulative loss: 4294953145
IA jitter: 0.0152
Their last SR: 2707816448
DLSR: 0.7610 (sec)

Why this parameters have this strange values?
Lost packets: 4294953145
Cumulative loss: 4294953145

As I see in rfc3550 this must be cumulative number of packets lost.

Today's cvs.

And from another call:
NOTICE[1008] sched.c: Attempted to delete nonexistent schedule entry 12!

By: Sergey Basmanov (sb) 2005-11-08 04:40:30.000-0600

After some time asterisk crashes with rtcp patch.
I got only two cores, and seems gdb can't read them properly:

Program terminated with signal 11, Segmentation fault.
warning: current_sos: Can't read pathname for load map: Input/output error

(gdb) bt full
#0 0x4002893e in pthread_mutex_lock () from /lib/tls/libpthread.so.0
No symbol table info available.
#1 0x080566a5 in ast_sched_del (con=0x0, id=685157) at lock.h:583
last = (struct sched *) 0x3f0
s = Variable "s" is not available.
(gdb) where
#0 0x4002893e in pthread_mutex_lock () from /lib/tls/libpthread.so.0
#1 0x080566a5 in ast_sched_del (con=0x0, id=685157) at lock.h:583
#2 0x080b2509 in ast_rtcp_write_sr (data=0x81b2250) at rtp.c:1519
#3 0x08056127 in ast_sched_runq (con=0x0) at sched.c:373
#4 0x404d9e1c in do_monitor (data=0x0) at chan_sip.c:11239
ASTERISK-1 0x400267d3 in start_thread () from /lib/tls/libpthread.so.0
ASTERISK-2 0x401c3b4a in clone () from /lib/tls/libc.so.6

and second:
#0 0x080b2577 in ast_rtcp_write_rr (data=0x81f8af8) at rtp.c:1563
1563 if(!rtp->rtcp->them.sin_addr.s_addr){
(gdb) bt full
#0 0x080b2577 in ast_rtcp_write_rr (data=0x81f8af8) at rtp.c:1563
res = Variable "res" is not available.
(gdb) where
#0 0x080b2577 in ast_rtcp_write_rr (data=0x81f8af8) at rtp.c:1563
#1 0x08056127 in ast_sched_runq (con=0x0) at sched.c:373
#2 0x404d9e1c in do_monitor (data=0x0) at chan_sip.c:11239
#3 0x400267d3 in start_thread () from /lib/tls/libpthread.so.0
#4 0x401c3b4a in clone () from /lib/tls/libc.so.6

also, after call hangup I see messages on console:

RTCP SR transmission error to 80.94.21.8:0 Bad file descriptor
Sent RTCP SR to 80.94.21.8:0

Looks like asterisk trying to send SRs after channel hangup.
By: Sergey Basmanov (sb) 2005-11-10 07:21:57.000-0600

I added some debug messages to rtp.c
So, this is what happens:
Nov 10 14:56:21 DEBUG[20722] chan_zap.c: Requested indication 14 on channel Zap/1-1
Nov 10 14:56:21 DEBUG[20722] chan_zap.c: Received AST_CONTROL_PROGRESS on Zap/1-1
Nov 10 14:56:21 DEBUG[20722] rtp.c: Added sched(ast_rtp_read/rr): 2300
Nov 10 14:56:21 DEBUG[20722] rtp.c: Added sched(ast_rtp_raw_write/sr): 2301
[skip]
Nov 10 15:00:05 DEBUG[20722] channel.c: Didn't get a frame from channel: Zap/1-1
Nov 10 15:00:05 VERBOSE[20722] logger.c: -- Hungup 'Zap/1-1'
Nov 10 15:00:06 DEBUG[17449] rtp.c: Deleting sched(ast_rtcp_write_sr/sr): 2301
Nov 10 15:00:06 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry 2301!
Nov 10 15:00:11 DEBUG[17449] rtp.c: Deleting sched(ast_rtcp_write_rr/rr): 2300
Nov 10 15:00:11 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry 2300!
Nov 10 15:00:11 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry -1!
Nov 10 15:00:16 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry -1!
Nov 10 15:00:16 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry -1!
Nov 10 15:00:21 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry -1!
Nov 10 15:00:21 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry -1!
Nov 10 15:00:26 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry -1!
Nov 10 15:00:26 NOTICE[17449] sched.c: Attempted to delete nonexistent schedule entry -1!
[core dump]

But must be something like this:
Nov 10 15:00:05 DEBUG[17449] rtp.c: Deleting sched(ast_rtp_destroy/rr): 2384
Nov 10 15:00:05 DEBUG[17449] rtp.c: Deleting sched(ast_rtp_destroy/sr): 2387

Seems that sip->sip calls going fine, while zap->sip have this issue.
By: Sergey Basmanov (sb) 2005-11-10 08:46:47.000-0600

I uploaded a log of adding/deleting schedulers..
A messages about parsing config means crash :)
By: Sergey Basmanov (sb) 2005-11-14 01:01:01.000-0600

Some additional info:
Nov 14 09:23:57 VERBOSE[24509] logger.c: -- Executing Dial("Zap/1-1", ... )
Nov 14 09:24:07 DEBUG[24509] rtp.c: Added sched (ast_rtp_read/rr): 785
Nov 14 09:24:07 DEBUG[24509] rtp.c: Added sched(ast_rtp_raw_write/sr): 786
Nov 14 09:24:07 VERBOSE[24509] logger.c: -- SIP/office-b620 answered Zap/1-1

Nov 14 09:26:21 VERBOSE[24509] logger.c: -- Hungup 'Zap/1-1'
Nov 14 09:26:22 DEBUG[25363] rtp.c: Deleting sched(ast_rctp_write/rr): 785
Nov 14 09:26:22 NOTICE[25363] sched.c: Attempted to delete nonexistent schedule entry 785!
Nov 14 09:26:22 DEBUG[25363] sched.c: Asterisk Schedule Dump (1 in Q, 790 Total, 5 Cache)
Nov 14 09:26:22 DEBUG[25363] sched.c: =============================================================
Nov 14 09:26:22 DEBUG[25363] sched.c: |ID Callback Data Time (sec:ms) |
Nov 14 09:26:22 DEBUG[25363] sched.c: +-----+-----------------+-----------------+-----------------+
Nov 14 09:26:22 DEBUG[25363] sched.c: |0786 | 0x80b25a0 | 0x822ebd8 | 000000 : 000117 |
Nov 14 09:26:22 DEBUG[25363] sched.c: =============================================================
Nov 14 09:26:22 WARNING[25363] rtp.c: Undefined rtp->rtcp->them.sin_addr.s_addr in ast_rtcp_write_sr !
Nov 14 09:26:22 DEBUG[25363] rtp.c: Deleting sched(ast_rtcp_write_sr/sr): 786
Nov 14 09:26:22 NOTICE[25363] sched.c: Attempted to delete nonexistent schedule entry 786!
Nov 14 09:26:22 DEBUG[25363] sched.c: Asterisk Schedule Dump (1 in Q, 790 Total, 5 Cache)
Nov 14 09:26:22 DEBUG[25363] sched.c: =============================================================
Nov 14 09:26:22 DEBUG[25363] sched.c: |ID Callback Data Time (sec:ms) |
Nov 14 09:26:22 DEBUG[25363] sched.c: +-----+-----------------+-----------------+-----------------+
Nov 14 09:26:22 DEBUG[25363] sched.c: |0785 | 0x80b2c50 | 0x822ebd8 | 000004 : 999396 |
Nov 14 09:26:22 DEBUG[25363] sched.c: =============================================================
By: Sergey Basmanov (sb) 2005-11-14 01:12:19.000-0600

And another call (20 minutes later):
Nov 14 09:42:30 VERBOSE[24733] logger.c: -- Zap/3-1 is ringing
Nov 14 09:42:30 DEBUG[24733] rtp.c: Added sched(ast_rtp_raw_write/sr): 795
Nov 14 09:42:30 DEBUG[24733] rtp.c: Added sched (ast_rtp_read/rr): 796
Nov 14 09:42:32 VERBOSE[24733] logger.c: -- Zap/3-1 answered SIP/office2-0821c5d0
Nov 14 09:46:56 VERBOSE[24733] logger.c: -- Hungup 'Zap/3-1'
Nov 14 09:46:57 DEBUG[25363] rtp.c: Deleting sched(ast_rctp_write/rr): 796
Nov 14 09:46:57 DEBUG[25363] sched.c: Asterisk Schedule Dump (2 in Q, 797 Total, 4 Cache)
Nov 14 09:46:57 DEBUG[25363] sched.c: =============================================================
Nov 14 09:46:57 DEBUG[25363] sched.c: |ID Callback Data Time (sec:ms) |
Nov 14 09:46:57 DEBUG[25363] sched.c: +-----+-----------------+-----------------+-----------------+
Nov 14 09:46:57 DEBUG[25363] sched.c: |0786 | 0x80b25a0 | 0x822ebd8 | 000000 : 000048 |
Nov 14 09:46:57 DEBUG[25363] sched.c: |0795 | 0x80b25a0 | 0x8254ce0 | 000003 : 058857 |
Nov 14 09:46:57 DEBUG[25363] sched.c: =============================================================
Nov 14 09:46:57 WARNING[25363] rtp.c: Undefined rtp->rtcp->them.sin_addr.s_addr in ast_rtcp_write_sr !
Nov 14 09:46:57 DEBUG[25363] rtp.c: Deleting sched(ast_rtcp_write_sr/sr): 795
Nov 14 09:46:57 DEBUG[25363] sched.c: Asterisk Schedule Dump (1 in Q, 797 Total, 5 Cache)
Nov 14 09:46:57 DEBUG[25363] sched.c: =============================================================
Nov 14 09:46:57 DEBUG[25363] sched.c: |ID Callback Data Time (sec:ms) |
Nov 14 09:46:57 DEBUG[25363] sched.c: +-----+-----------------+-----------------+-----------------+
Nov 14 09:46:57 DEBUG[25363] sched.c: |0785 | 0x80b2c50 | 0x822ebd8 | 000004 : 999351 |
Nov 14 09:46:57 DEBUG[25363] sched.c: =============================================================
Nov 14 09:47:02 WARNING[25363] rtp.c: Undefined rtp->rtcp->them.sin_addr.s_addr in ast_rtcp_write_sr !
By: Sergey Basmanov (sb) 2005-11-15 03:32:50.000-0600

Added full trace + asterisk debug log.
Any ideas why this happens?
By: Sergey Basmanov (sb) 2005-11-16 15:28:25.000-0600

Seems I found why it crashed..
First, when ast_rtcp_write_(sr/rr) called by sched, this sched is not available in sched list (rtp->sched).. This is why 'sched.c: Attempted to delete nonexistent schedule entry' messages.. And when rtp->rtcp and rtp freed, value of pointer rtp->rtcp becomes 0x2960 (at least on my system). So, when next time one of the ast_rtcp_write_(sr/rr) called on already freed rtp->rtcp, asterisk crashes..
Any ideas? How to delete schedule enrty from ast_rtcp_write(sr/rr) ?
And I think just to be sure we need to set: rtp->rtcp=NULL just right after: free(rtp->rtcp).
As workaround I think it's possible to delete rr_sched from write_sr and sr_sched from write_rr.
Any suggestions?
By: Sergey Basmanov (sb) 2005-11-16 15:46:49.000-0600

Added patch against current cvs. Main difference with previous patch - in ast_rtcp_write_sr I delete rr_schedid, and in ast_rtcp_write_rr I delete sr_schedid.
By: Sergey Basmanov (sb) 2005-11-17 04:50:05.000-0600

According to comments in ast_sched_runq it's better to return 0 from callback instead of trying to delete schedule entry. In this patch both callback functions return 0 on errors.
By: Serge Vecher (serge-v) 2005-11-18 17:41:12.000-0600

OK: I've patched the 11/18/2005 HEAD with rtp_h_patch.text (11-04-05) and rtcp_patch2.diff (11-17-05):
* Nothing seems broken, which is a good thing :)
* There were minor warnings during compilation -- perhaps those can be taken care of

gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -g3 -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O6 -march=i686 -DZAPTEL_OPTIMIZATIONS -fomit-frame-pointer -c -o rtp.o rtp.c
rtp.c:195: warning: no previous prototype for âtimeval2ntpâ
rtp.c:217: warning: no previous prototype for âast_rtcp_calc_intervalâ
By: Sergey Basmanov (sb) 2005-11-19 12:47:09.000-0600

Fixed compilation warning (rtp_h_rtcp.diff)
Added rtp->rtcp=NULL right after free(rtp->rtcp) because it's still possible that ast_rtcp_write_sr/rr can be called after rctp structure deallocated..
(I had one crash since 17/11)
Also, I added cli command: rtp rtcp stats
for dumping rtp stats after each call (and not to fill logs with rtcp debug).
vechers: Can You please test this patch?
By: Serge Vecher (serge-v) 2005-11-19 21:32:30.000-0600

sb: applied rtcp_patch3.diff/rtp_h_rtcp.diff:
1) Compilation warnings gone
2) Things still work with light weekend traffic :)
3) Will leave the patch on production server for Monday

oej: perhaps this could be considered to CVS candidacy at this point?
bugmarshalls: I think the attachments need some cleanup -- the relevant ones are: rtcp_chan_sip.patch, rtcp_patch3.diff, rtp_h_rtcp.diff . I believe the logs/traces point to issues that have been resolved in the latest patch by SB. Please correct me if I am wrong.

Thanks!
By: Serge Vecher (serge-v) 2005-11-21 08:59:27.000-0600

Unfortunately there are still problems: This happened on our production server this morning, followed by a segfault:

[Nov 21 09:48:15] WARNING[1245]: interface.c:215 decodeMP3: Junk at the beginning of frame 49443303
[Nov 21 09:48:25] WARNING[1245]: interface.c:215 decodeMP3: Junk at the beginning of frame 49443303
[Nov 21 09:48:36] NOTICE[1239]: sched.c:296 ast_sched_del: Attempted to delete nonexistent schedule entry 212!

Unfortunately, can't produce backtraces on this server. I will set up another test server for further patches.
By: Sergey Basmanov (sb) 2005-11-21 10:11:48.000-0600

Hmm.. ast_sched_del called only from ast_rtp_destroy..
Here is a code:
if(rtp->rtcp->rr_schedid>0){
ast_sched_del(rtp->sched, rtp->rtcp->rr_schedid);
rtp->rtcp->rr_schedid = -1;
}

if(rtp->rtcp->sr_schedid>0){
ast_sched_del(rtp->sched, rtp->rtcp->sr_schedid);
rtp->rtcp->sr_schedid = -1;
}
So, rtp->rtcp can't be already freed before this call (as it was inside callbacks). And one of schedid can be > 0 but without sched entry only in case when one of callbacks returned zero in case of (!rtp || !rtp->rtcp) is true.
Also, attempt to delete nonexistent sched entry doesn't cause segfault, but only warning message..
So, backtrace will be really useful..
By: Serge Vecher (serge-v) 2005-11-21 13:43:20.000-0600

sb: I've recompiled Asterisk from CVS this morning (no RTCP patches applied) and it doesn't crash any more. I will try to set up a non-optimized build on the server and attempt to recreate the problem, hopefully producing a backtrace.
By: Olle Johansson (oej) 2006-01-03 15:43:24.000-0600

Ok, let's start another attempt to get this into SVN. Is this patch updated to current svn trunk?
By: Justin Unger (justinu) 2006-01-03 15:56:33.000-0600

Some general thoughts on this patch so far:

Every device I've seen that implements RTCP sends SR (sender reports) packets. These packets contain both an SR and a RR (receiver report) block. Currently, the patch doesn't decode the RR which is tacked on the SR packet. I have modified it to do so.

This patch sends it's receiver reports in RR packets. The RFC3550 spec says that you should only use RR if you're not currently an active sender. If you're an active sender, you should use the SR packet type with your RR appended to the end. I've made the required modifications to the patch for this as well.

I believe this is the reason you get some bogus values in the report issued at the end of the call.

Another note is that both the Polycom 501 and eyebeam softphone seem not to compute the DLSR value correctly in their receiver reports. This causes some more bogus values to be printed out at the end of the call, but I don't think there's anything we can do about it at this point.
By: Justin Unger (justinu) 2006-01-03 16:02:17.000-0600

Folsson: sorry it took so long to get back to you on this, but it turns out that L3 doesn't even have support for RTCP! :(

What I can do is go over some of the pcap traces of RTCP from the polycom 501, aastra 480i, gxp2000, spa841, eyebeam, xlite, etc. if you're interested.
By: Olle Johansson (oej) 2006-01-04 05:39:36.000-0600

justinu: I need a confirmation that you have a disclaimer on file for this patch.
By: ennuyeux72 (ennuyeux72) 2006-01-05 04:20:06.000-0600

I have been using the patch in a production environment since this morning. The cvs is from the end of December 2005 CVS HEAD. I have had 2 core dumps but cannot work out what the trigger is. There were some calls going through fine at the time. I was able to do a quick backtrace on the most recent core dump and am posting the results. Hope it is of some use. Let me know if more info is needed.

#0 ast_rtcp_write_rr (data=0x82102b8) at rtp.c:1569
res = 135519752
lost = 0
expected = 0
expected_interval = 136438464
received_interval = 1
lost_interval = 0
now = {tv_sec = 0, tv_usec = 0}
bdata = '\0' <repeats 976 times>, "p\234ù·@\000\000\000\201\236ù· ùÿ¾\001\000\000\000\036¤ù·àûÿ¾ôï ù·\bÞ\023\bè\003\000\000Ìùÿ¾°dù·"
iabuf = '\0' <repeats 15 times>
dlsr = {tv_sec = 0, tv_usec = 0}
fraction = 0
#1 0x08056238 in ast_sched_runq (con=0x813de08) at sched.c:373
tv = {tv_sec = 0, tv_usec = 1}
x = 0
res = 136438464
#2 0xb7b6defa in do_monitor (data=0x0) at chan_sip.c:11260
res = 135519752
sip = (struct sip_pvt *) 0x813de08
peer = (struct sip_peer *) 0x813de08
t = 1136458408
fastrestart = 0
lastpeernum = -1
curpeernum = 5
reloading = 135519752
#3 0xb7f951de in pthread_start_thread () from /lib/libpthread.so.0
No symbol table info available.
By: Olle Johansson (oej) 2006-01-05 04:45:09.000-0600

folsson: Can you help trace this bug?
By: Sergey Basmanov (sb) 2006-01-06 16:17:19.000-0600

oej: Seems it's a little difficult to find why it crashes.. :) But I have a suggestion. Because scheduler works independently of main process (I mean code in rtp.c), it's better to use some locking mechanism to avoid situations when sched entry called with non-actual data (already freed pointers or something else). So, allocation and deletition of scheduler entries must be in sync with allocation and deletition of data structures..
Any ideas?
By: Olle Johansson (oej) 2006-01-26 08:37:17.000-0600

folsson: Please come back to this issue :-)
By: Olle Johansson (oej) 2006-02-02 02:36:11.000-0600

FYI:
http://www.softarmor.com/wgdb/docs/draft-johnston-sipping-rtcp-summary-06.txt
By: John Martin (jfp_martin) 2006-02-03 03:43:10.000-0600

Everyone,
I've just uploaded a couple of patches for rtp.c and rtp.h. The following have been addressed:
- I've fixed the seg faulting problems that I'd been seeing (SIP, H.323 and ISDN tested) and added support for multi-part SR/RRs coming in. Seg faults seemed to be coming from rtcp_stop not disabling the next scheduled SR/RR from being sent. When this last SR/RR send was entered the checks on the them.addr were not sufficient to see that parts of the them.addr structs had been memset to 0 already. I think there may still be a vulnerability to rtcp_stop being called while SR/RRs are being sent but I've not seen this on any of my systems so if it is a problem someone had better let me know and I'll put the full mutex protection around the SR/RR writing etc.
- There's also support for sending H.261 fast update requests (as needed by Huawei and other video endpoints) - though this will need patches to chan_sip to work correctly.
- I've also fixed a problem in the previous patches where mal-formed RTCP packets were being sent out (not long enough).

I know others have been working on other fixes but I need to get this moving again.
John
By: John Martin (jfp_martin) 2006-02-03 03:45:01.000-0600

Oh, there's also support for multi-part RTCP packets - you should always send out at least two chuncks and some endpoints send out even more than that.

John
By: Olle Johansson (oej) 2006-02-03 03:54:36.000-0600

AuPix: You need to confirm your disclaimer for these patches in this error report.

Thank you for your work, AuPIX. I will open a branch for testing soon, but meanwhile I look forward to all test reports from everyone monitoring this bug report! I do appreciate all of you spending some time testing this and confirming your results here, so we can move forward on this.
By: Neil Stratford (Vipadia Limited) (fenlander) 2006-02-05 08:35:26.000-0600

I've been testing this over the weekend and have not seen a segfault yet.

However, I think that there may be a bug in the rtcp header: from the RFC the length should be set to the length of the RTCP packet in 32-bit words minus one, including the header and any padding.

So for the SR (with a reception report) it should be 12 rather than 6:
rtcpheader[0] = htonl((2 << 30) | (1 << 24) | (RTCP_PT_SR << 16) | 12 /* was 6 */);

and similarly for the RR it should be 7 rather than 6.

Neil
By: John Martin (jfp_martin) 2006-02-05 08:45:56.000-0600

Well spotted fenlander. I remember thinking "I need to sort that out" but didn't.

I'll put a patch up in a bit.

John
By: John Martin (jfp_martin) 2006-02-05 09:08:07.000-0600

Fenlander,
I've made the length in the header be calculated from whatever gets put in the report.
The next thing is really to only send RRs when there hasn't been any outbound RTP in the time interval.
I was also thinking that the RTCP time interval should be settable in rtp.conf. Anyone with any thoughts on this?

John
By: Neil Stratford (Vipadia Limited) (fenlander) 2006-02-05 10:10:55.000-0600

Hi John, thanks for the quick update!

Should the 'rtcpheader[0] =' line be before the H.261 FIR section instead of after? I'm not using H.261 FIRs (RFC 2032?) so I'm not sure, but it looks like a new RTCP header in a compound RTCP packet, in which case the length shouldn't be included in the previous RTCP header?

I agree with you that it would be nice to control the minimum interval from rtp.conf.

Another couple of things for us to consider:

- I have a client that sends RTCP BYE packets, which at the moment give "Unknown RTCP packet (pt=203)" notices. I don't think that we need to do anything with them at the moment, but maybe we could 'if(rtcp_debug_test_addr(&sin)){' a debug message.

- Should we send SDES packets?

Neil
By: John Martin (jfp_martin) 2006-02-05 11:56:56.000-0600

Thanks for the reply Fenlander,
I think you're right about the headers. I need to spend a couple of hours getting this into better shape. I think I've seen Cisco kit fairly reliably send BYE, so can knock that out of the "don't know" default. I'll add a debug clause for it.

We always send SDES in our products, and most reputable RTCP senders do too I think. It gets round the problem of always having to send two RTCP packets in each IP packet and gives you something readable to look at.

Can someone with more privs than me knock out all the extraneous files now please. I'd vote for just keeping rtp_c_9060_2.patch and rtp_h_9060.patch

regards, John
By: John Martin (jfp_martin) 2006-02-06 04:28:49.000-0600

Fenlander, et al
I've uploaded rtp_c_9060_3.patch. It does the following:

- RTCP interval can be set in rtp.conf (interval in ms)
min 500, max 60000, default 5000
[general]
rtcpinterval=value

- BYE packets no longer generate log output only trace if selected.
- SDES packets are added to each IP packet, they're empty for the moment though
- only a single scheduler is used now. It decides if it needs to send an RR or SR depending on what packets have been sent.

John
By: Olle Johansson (oej) 2006-02-09 07:50:09.000-0600

Creating branch "rtcp". From now on, please upload patches for that branch, not for trunk. Thank you.

http://svn.digium.com/svn/asterisk/team/oej/rtcp

More information on branches:
* http://www.asterisk.org - developer section
* http://www.voip-forum.com
By: Olle Johansson (oej) 2006-02-09 08:12:45.000-0600

Creating branch "rtcp". From now on, please upload patches for that branch, not for trunk. Thank you.

http://svn.digium.com/svn/asterisk/team/oej/rtcp

More information on branches:
* http://www.asterisk.org - developer section
* http://www.voip-forum.com
By: puzzled (puzzled) 2006-02-17 05:56:01.000-0600

Hi, I made a version of rtp_c_9060_3.patch that applies cleanly to asterisk-1.2.4. Compilation with gcc-4.0.2 on Fedora Core 4 shows a couple of warnings. I am not C proficient enough to fix these warnings so any help is most welcome. This patch is totally untested other than that Asteirsk compiles with it and it starts. Warnings:
gcc -pipe -Wall -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Iinclude -I../include -D_REENTRANT -D_GNU_SOURCE -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona -DZAPTEL_OPTIMIZATIONS -m64 -fomit-frame-pointer -DT38_SUPPORT -c -o rtp.o rtp.c
rtp.c:204: warning: no previous prototype for 'timeval2ntp'
rtp.c:226: warning: no previous prototype for 'ast_rtcp_calc_interval'
rtp.c:1335: warning: no previous prototype for 'ast_rtp_get_quality'
rtp.c:1495: warning: no previous prototype for 'ast_rtcp_send_h261fur'
rtp.c:1506: warning: no previous prototype for 'ast_rtcp_write_sr'
rtp.c:1618: warning: no previous prototype for 'ast_rtcp_write_rr'
By: John Martin (jfp_martin) 2006-02-17 07:30:44.000-0600

Hi Puzzled,
Did you also apply the rtp.h patch for 9060 as well (rtp_h_9060.patch)? Your rtp.h may not have the fuction declarations in it. I'd also like to point you to OEJs advice that patches should be submitted relative to his rtcp branch (see the posting directly before yours) - it's going to get pretty messy if we have to keep two threads running...

Have you tried capturing trace of the RTCP packets on any systems you have? Do you have any endpoints that use RTCP?

thanks, John
By: puzzled (puzzled) 2006-02-17 08:07:21.000-0600

Thanks for the pointer John. Totally overlooked the header file. New patch uploaded that includes the rtp.h changes which seems to have fixed the warnings. To answer your question: I have not captured any RTCP packets yet. I'm aware of Digium's position to not add any new stuff to "stable" (or whatever it's called these days). Using HEAD is often not an option. Hence my efforts to create a patch for 1.2.4.
By: Olle Johansson (oej) 2006-03-09 14:23:05.000-0600

I would like to see the end-of-call report in channel or -even better- CDR variables. Any coders?
By: Jeffrey C. Ollie (jcollie) 2006-03-31 12:20:16.000-0600

In ast_rtcp_read, the buffer size given to recvfrom is computed incorrectly. A patch against test-this-branch has been uploaded (disclaimer on file).
By: Olle Johansson (oej) 2006-03-31 13:32:19.000-0600

Committed to the rtcp and the test branch. Thanks!
By: John Martin (jfp_martin) 2006-04-10 07:14:55

New patch against todays team/oej/rtcp/ branch (17651) has been uploaded. I fixed the following problems:

- The cycles variable was incorrectly shifted by 16 bits when added to the rtcp reports (it's already shifted by that amount). This could cause a large jump in the extended seqno.
- Fraction lost was incorrectly calculated if there were more rtp packets arrived than expected (lost_interval was unsigned int, should be int).
- An rtcp packet with a payload of h261_fur (fast update request) now returns a frame containing AST_CONTROL_VIDUPDATE rather than ast_null_frame.
- Fixed some compiler warnings regarding debug output.

John
By: Olle Johansson (oej) 2006-04-10 07:36:43

stevek: How do we link to the IAX2 receiver reports?
By: Olle Johansson (oej) 2006-04-10 07:45:07

New patch merged into branch.
By: stevekstevek (stevekstevek) 2006-04-10 08:32:52

oej
04-10-06 07:36
stevek: How do we link to the IAX2 receiver reports?

I'm not sure what you mean, in particular. I wrote here on 01-19-05 18:51 that some coordination should be done..

It's my opinion that when calls are bridged, either within the same protocol, or between protocols, in most cases RR's should probably be bridged as well. in other words, if you have a call that goes like this:

UserAgentA <-LegA-> Asterisk [<-otherlegs-> Asterisk (or more)] <-LegB-> UserAgentB, then the RR's being sent to UserAgentA and UserAgentB probably should include the metrics for the entire call (media) path, not just the hop between Asterisk and the user agent.

To do that, you basically want Asterisk, when a call is bridged, to just forward the RR's along from one side of the bridge to the other, translating the "format" of the RR's if necessary.

The IAX2 RRs are more or less compatible with RTP RTCP RR's; I would expect that you'd be able to just shuffle things around or maybe just do a copy to bridge them across.
By: Olle Johansson (oej) 2006-04-10 08:57:34

stevek: Well, I noticed your old comment while browsing through this bug report, so I was curious on your thoughts. Guess what we're looking for long-term is a standard Asterisk way to handle RR reports...
By: John Martin (jfp_martin) 2006-04-10 11:44:28

SteveK, OEJ,
perhaps I can throw a comment in here. I agree with SteveK Asterisk really needs to deliver end to end SR's and RR's. The problem also comes with the way Ast uses it's own seqno and ssrc. You can get into all sorts of a mess when doing stuff like IVR followed by a transfer; where there can be big jumps in seqno or the ssrc changing. The spec says you can do it and tells you what to do in such a scenario but there are endpoints out there that barf when you do :-( I've raised the point before that Ast needs to be more careful with seqno's (when you get packet reversal in a network Ast will throw away the inbound seqno and put sequential seq no's on out of sequence packets). Jitterbuffer can be where you do this reordering I guess, but structures like ast_frame need to cary the seqno's around for other apps/channels to make sense of.

Just adding to the debate...

John Martin
By: Olle Johansson (oej) 2006-04-11 11:05:14

Ok, but that's future stuff, now we need to complete this work and get it into Asterisk.

I need help with adding code for publishing stuff from RTCP as channel variables, soemthing that makes sense so you can either add it to a log file or the CDR from the dial plan. Even better, let's add it as a CDR(rtcp) variable...
By: Olle Johansson (oej) 2006-05-17 14:55:47

Anyone that can add code to put the report in a CDR variable? We need to complete this work so we can get it into 1.4. That should have been completed, well, a few weeks ago...
By: phsultan (phsultan) 2006-05-22 13:10:05

The 'stun_no_debug' function name is missing in rtp.c, which prevents the 'rtcp' branch from compiling. Fixed in rtcp-rtp_stun_no_debug.patch (disclaimer sent).
By: Olle Johansson (oej) 2006-06-05 03:40:11

Committed to svn trunk, rev 32230.

A big thankyou to everyone involved in this work - development, testing, fixing!
By: Olle Johansson (oej) 2006-06-05 03:45:05

Branch removed.
By: Digium Subversion (svnbot) 2008-01-15 16:34:48.000-0600

Repository: asterisk
Revision: 9290

_U team/oej/rtcp/
U team/oej/rtcp/rtp.c

------------------------------------------------------------------------
r9290 | oej | 2008-01-15 16:34:48 -0600 (Tue, 15 Jan 2008) | 2 lines

Patch from issue ASTERISK-2815 - implement RTCP

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=9290