Summary:ASTERISK-11265: [patch] app_rtpstream: Application to Page Multicast capable receivers (e.g. Snom, Linksys, Cisco, Barix devices)
Reporter:Andy Brodmann (macbrody)Labels:
Date Opened:2008-01-19 04:46:10.000-0600Date Closed:2009-06-25 13:26:26
Versions:Frequency of
Environment:Attachments:( 0) app_rtppage-20090312-02.c
Description:app_rtpstream is an application that reads the input channel's voice frames and does rtp stream them to either unicast or multicast addresses defined as groups in the config file.

This can be used for example with the Snom and Linksys IP Phones' feature to do paging to multicast receivers.
Comments:By: Olle Johansson (oej) 2008-01-21 04:06:23.000-0600

Any way we can use this feature for musiconhold? I think some phones receive musiconhold music on multicast.

If so, it propably should not be an app anymore :-)

By: Andy Brodmann (macbrody) 2008-01-21 04:08:00.000-0600

Added the corrected version of app_rtpstream.c, thanks oej

By: Andy Brodmann (macbrody) 2008-01-21 04:20:41.000-0600

This application is just for paging multicast enabled phones (like snom, linksys) instead of using app_page which itselfs uses meetme. The advantage of this is ressource saving on small / embedded systems.

I'll have a look at how we can use this feature for musiconhold as well but this app here is just for paging.

By: Andy Brodmann (macbrody) 2008-01-21 06:38:14.000-0600

As requested by oej, I renamed the app to app_rtppage.c, resp. RTPPage in the dialplan. The config file was renamed to rtppage.conf to comply with the app's name.

Please remove the old named files: app_rtpstream.c and rtpstream.conf

By: Andy Brodmann (macbrody) 2008-01-23 08:38:33.000-0600

I have uploaded a slightly modifed version:

it includes credits to Brian West for the Information
he gave me regarding multicast paging with Linksys phones
and that this information was used with his permission.

Please replace app_rtppage.c with app_rtppage-2008012301.c

sorry for the inconvenience.

By: Olle Johansson (oej) 2008-01-23 08:46:06.000-0600

Would being able to specify unicast IP on the command line make sense?

Like rtppage(SIP_PEER(olle, ip), SIPPEER(alex, IP));
to get the IP address they're registered with?


By: Andy Brodmann (macbrody) 2008-01-23 08:52:11.000-0600

yes, I suggest though that we then make two applications from it, like:

1) RTPPage_Multicast(group1[&group2][, codec])
2) RTPPage_Unitcast(ip1 & ip2 & ip3[, codec])

Just where do we get the port to send it to from, if
we use SIP_PEER? And is there a SIP client who handles
unicast RTP without signalling?

The other use for unicast RTP are clients like the Barix Extreamer.

What do you think?

By: Olle Johansson (oej) 2008-01-23 09:00:20.000-0600

Well, there are RTP servers out there that you can initialize in other ways. Maybe it is just a new first argument to the app

rtppage(direct, IP, codec)
rtppage(multicast, group, codec)

the sip peer dialplan function in trunk now gives port as well.

By: Andy Brodmann (macbrody) 2008-01-24 07:34:10.000-0600

ok oej,

as you suggested I modified the app to expect another first

RTPPage(direct|multicast, ip:port[&ip:port]|group1[&group2][,codec])

if direct is chosen then it exptects ip:port pairs instead of groups.

The new version is: app_rtppage-2008012401.c

By: Kristian Kielhofner (krisk84) 2008-01-29 15:31:43.000-0600

Would it be possible to expand this application to work with multiple phones that don't support multicast RTP in SNOM or Linksys mode?

In RFC 4566, section 5.7 you should be able to specify a multicast address for c=.  It would be neat to send unicast SIP INVITEs to each phone and specify a multicast address for them to listen on in the SDP.  That way you would still only have to send the RTP out once.

By: Andy Brodmann (macbrody) 2008-01-29 16:01:55.000-0600

Two answers:

1) I'd like the application in the current status to be part of asterisk 1.6
  if possible. Oej, anyone at digium, what do you think? Anything we can help
  you with?

2) Anything is possible ;). I have yet to find out how to best integrate this
  with the channel driver though, as in this special case I'd like the
  signalling to go via channel driver if possible.

are there any devices on the market that support case #2?

By: Olle Johansson (oej) 2008-01-30 02:16:58.000-0600

I think we should keep this application as is for now and I'll get it in soon (just home from a business trip).

Other ideas are always welcome on asterisk-dev mailing list or www.asteriskideas.org


By: Olle Johansson (oej) 2008-01-30 07:37:55.000-0600

I can't get it to compile with svn trunk - can you please check?

By: Andy Brodmann (macbrody) 2008-01-30 08:08:46.000-0600


I just did 'svn up' on trunk, copied the file app_rtppage-2008012401.c
to apps/app_rtppage.c and then did ./configure ... && make.

it worked here.

What error messages do you get?

By: Olle Johansson (oej) 2008-01-30 08:27:44.000-0600

[CC] app_rtppage.c -> app_rtppage.o
app_rtppage.c: In function 'rtppage_exec':
app_rtppage.c:140: error: nested functions are disabled, use -fnested-functions to re-enable
app_rtppage.c:140: error: invalid storage class for function '__init_activegroups'
app_rtppage.c:140: warning: no previous prototype for '__init_activegroups'
app_rtppage.c:140: error: nested functions are disabled, use -fnested-functions to re-enable
app_rtppage.c:140: error: invalid storage class for function '__fini_activegroups'
app_rtppage.c:140: warning: no previous prototype for '__fini_activegroups'

By: Andy Brodmann (macbrody) 2008-01-30 08:47:47.000-0600

Line 140 is: AST_LIST_HEAD_STATIC(activegroups, mcast_group);

this is an asterisk macro. I used it non-static within the rtppage_exec
function to declare a temporary structure/list, which is unique for
each instance calling this application.

Is the use of AST_LIST_HEAD_STATIC not allowed for local variables within
functions? Or do I have to use AST_LIST_HEAD instead and initialize the
structures fields myself? (It seems the automatic initialization by the macro
is considered a nested function which is not allowed on your system - Is this
general policy for asterisk?)

By: Olle Johansson (oej) 2008-01-30 08:50:38.000-0600

I don't think you can do that within a function, move it outside and test.

By: Olle Johansson (oej) 2008-01-30 08:52:49.000-0600

That worked.

By: Andy Brodmann (macbrody) 2008-01-30 08:54:54.000-0600

ok, just to be sure:

if I move it to the global scope, will multiple simultaneous
calls to app_rtppage use the same memory for this structure or
will they each have their own memory space?

this structure has to be independant for each simultaneous call
to app_rtppage.

By: Olle Johansson (oej) 2008-01-30 09:01:37.000-0600

Global static is global. So you don't want to use that macro I guess.

By: Andy Brodmann (macbrody) 2008-01-30 09:22:02.000-0600

solution and new file uploaded: app_rtppage-20080130.c

I replaced line 140 with the use of "AST_LIST_HEAD(" instead
of "AST_LIST_HEAD_STATIC(" and then initialized the fields manually.

I declared it local and non-static to be sure multiple simultaneous
occurances don't interfere with each other.

By: Digium Subversion (svnbot) 2008-01-30 09:27:54.000-0600

Repository: asterisk
Revision: 101218

A   trunk/apps/app_rtppage.c
A   trunk/configs/rtppage.conf.sample

r101218 | oej | 2008-01-30 09:27:52 -0600 (Wed, 30 Jan 2008) | 8 lines

Add rtppage() application to do multicast or unicast RTP paging to SIP phones.

(closes issue ASTERISK-11265)
Reported by: macbrody
     app_rtppage-20080130.c uploaded by macbrody (license 352)



By: Olle Johansson (oej) 2008-01-30 09:28:03.000-0600

Thanks for your contribution to asterisk and for coming back with requested changes!


By: Olle Johansson (oej) 2008-01-30 11:11:51.000-0600

Re-opening as this code wasn't approved for trunk.

By: Kristian Kielhofner (krisk84) 2008-01-30 11:20:20.000-0600

Any RFC compliant SIP device *SHOULD* support case 2. It shouldn't be that tough to whip up something to test this functionality (says the guy who doesn't know how to do it).

By: Olle Johansson (oej) 2008-01-30 11:40:30.000-0600

Comments made on this code:
+ * Information on how multicast paging works with linksys
+ * phones was used from FreeSWITCH's mod_esf with permission
+ * from Brian West.

All references to company names (especially trademarked ones) should be
properly capitalized. There are many places in this file that should be

+ <defaultenabled>yes</defaultenabled>
+ ***/

This is unnecessary, as the default for modules is 'enabled'.

+#define RTP_PT_ULAW    0
+#define RTP_PT_GSM     3
+#define RTP_PT_ALAW    8
+#define RTP_PT_G729   18

This information is already in the static_RTP_PT table in main/rtp.c and
shouldn't be duplicated here. An accessor function that takes an
Asterisk format code and returns the RTP payload type from that table
would provide what is needed here.

+static char *app = "RTPPage";
+static char *synopsis = "RTPPage Application";

Can we have something more description that just repeating the
application's name and adding 'Application'?

+static char *descrip = "  RTPPage(direct|multicast, ip:port[&ip:port]|group[&group2[&group3...]][,codec]): Sends the channel's input to the\n"
+"specified group(s) defined in the config file rtppage.conf.\n"
+"The optional codec may be one of the following:\n"
+"   ulaw - default\n"
+"   alaw\n"
+"   gsm\n"
+"   g729\n"
+"as long as asterisk does not have to translate or respective translators are\n"
+"installed with your asterisk installation. If none or any other codec is\n"
+"specified the application will fall back to ulaw.\n";

Why does this not support all formats that are defined in our
static_RTP_PT in main/rtp.c? At a minimum the addition of G.726 and
G.722 could be useful.

+ /* allocate memory for the rtp send buffer */
+ if ((databuf = ast_calloc(1, 172)) == NULL) {
+ ast_log(LOG_WARNING, "Failed to allocate memory for the data buffer, give up\n");
+ goto end;
+ }

This makes an assumption about the amount of data to be sent... see below.

+ /* initialize rtp buffer header
+ * with rtp version and
+ * payload type
+ */
+ rtph = (struct rtp_header *)databuf;

I would prefer to see this buffer just allocated as a 'struct
rtp_header' instance and define that structure to contain a 'char
data[0]' element at its end for reading and writing the payload portion
of the frame.

+ rtpflags  = (0x02 << 14); /* rtp v2 */
+ rtpflags  = (rtpflags & 0xFF80) |  rtp_pt;  
+ rtph->flags = htons(rtpflags);
+ rtph->ssrc =  htonl((u_long)time(NULL));
+ /* first create a temporary table for this page session
+ * containing all groups which will be used
+ */
+ AST_LIST_LOCK(&groups);
+ rest = ast_strdup(args.groups);

There is no need to duplicate this string, as the one in args.groups is
already modifiable and no other usage of the original string is
necessary. In addition, this allocation is never freed and couldn't be
because the pointer to the base of the copied string is not preserved

+ struct mcast_group *agroup = ast_calloc(1, sizeof(*agroup));

No check for allocation failure.

+ rest2 = ast_strdup(cur);

Same comment as above; there is no need for a copy, and this is a memory

+ struct mcast_group *agroup = ast_calloc(1, sizeof(*agroup));

No check for allocation failure.

+ memcpy(agroup->name, group->name, 32);
+ agroup->type = group->type;
+ agroup->socket = group->socket;
+ agroup->ttl = group->ttl;
+ memcpy(&agroup->rtp_address, &group->rtp_address, sizeof(agroup->rtp_address));
+ memcpy(&agroup->control_address, &group->control_address, sizeof(agroup->control_address));

If we are going to copy the entire group, then just copy the whole group
using '*agroup = *group;' and then 'AST_LIST_NEXT(agroup, list) = NULL;'.

+ AST_LIST_TRAVERSE(&activegroups, group, list) {
+ group->socket = socket(AF_INET, SOCK_DGRAM, 0);

No check for socket creation failure.

+ memcpy(&destaddr, &group->control_address, sizeof(destaddr));

'destaddr = group->control_address;'

+ sendto(group->socket, &cpk, sizeof(cpk), 0, (struct sockaddr *)&destaddr, sizeof(destaddr));
+ sendto(group->socket, &cpk, sizeof(cpk), 0, (struct sockaddr *)&destaddr, sizeof(destaddr));

If there is a specific reason why this packet is being sent twice, it
would be helpful if it was noted in a comment here.

+ ast_log(LOG_DEBUG, "Hangup detected\n");

Please ast_debug() and ast_verb() for log messages.

+ if ((f->frametype == AST_FRAME_DTMF) && (f->subclass == '#')) {
+ res = 0;
+ ast_frfree(f);
+ ast_log(LOG_DEBUG, "Received DTMF key: %d\n", f->subclass);

You can't access f->subclass when you just freed the frame with

+ memcpy(databuf+12, f->data, f->datalen);

This is very bad. This will copy an unpredictable amount of data into a
fixed-size buffer. The channel running this application could supply
voice frames with any number of samples it wishes. Either this code will
need to grow the size of the databuffer to match the largest incoming
frame it has seen, or it will need to use a smoother to intentionally
read known-size frames from the incoming channel (although that won't
work for G.729 and G.723 because they are not smoothable in the same way
that sample-based codecs are).

+ memcpy(&destaddr, &group->rtp_address, sizeof(destaddr));

Again a direct structure copy can be used.

+ if (sendto(group->socket, databuf, f->datalen+12, 0, (struct sockaddr *)&destaddr, sizeof(destaddr)) <= 0) {
+ ast_log(LOG_DEBUG, "sendto() failed!\n");
+ }

If the sendto() fails, we don't get a useful error message (including
the translated error text, and no attempt is made to close the socket if
it is no longer usable, so the console will be spammed with failure
messages for each incoming frame. In addition, a serious failure like
this should not be LOG_DEBUG.

+ AST_LIST_LOCK(&groups);
+ if (reload) {
+ /* if this is a reload, then free the config structure before
+ * filling it again
+ */
+ while ((group = AST_LIST_REMOVE_HEAD(&groups, list))) {
+ free(group);
+ }
+ /* reset default_ttl & tos */
+ default_ttl = -1; /* means not set */
+ tos = -1;
+ }

The actual paging code accesses default_ttl and tos outside the 'groups'
lock, so these changes could affect existing paging calls that are being
setup during the reload.

+ return(-1);

Don't treat return as if it was a function :-)

+ var = ast_variable_retrieve(cfg, cat, "tos");
+ if (var) {
+ ast_str2tos(var, &tos);
+ }

No error check to see if the supplied TOS string was invalid.

+ group = ast_calloc(1, sizeof(*group));

No check for allocation failure.

+ memset(&group->rtp_address, 0, sizeof(group->rtp_address));

This is unnecessary, as the memory for the structure was allocated with

+ group->rtp_address.sin_port = htons(atoi(ast_variable_retrieve(cfg, cat, "rtp_port")));

If no rtp_port was specified, this will segfault.

+ if (inet_pton(AF_INET, ast_variable_retrieve(cfg, cat, "rtp_address"), &group->rtp_address.sin_addr) <= 0) {

Same thing here... no rtp_address specified, segfault.

+ group->type = -1;
+ group->socket = -1;
+ group->ttl = -1;
+ ast_log(LOG_NOTICE, "Invalid mcast group %s!\n", cat);
+ continue;

Memory leak. The next cycle through this loop will allocate another
group structure. There is no need to reset the fields in this one, it
should just be freed before the log message. Also, configuration errors
should be at least LOG_WARNING, if not LOG_ERROR.

+ ast_log(LOG_NOTICE, "loaded category %s\n", group->name);

This is excessive and seems like a leftover debugging message from

By: Andy Brodmann (macbrody) 2008-01-30 15:58:15.000-0600


I will rewrite the code as requested. Just two things to start with:

> +#define RTP_PT_G729 18
> This information is already in the static_RTP_PT table in main/rtp.c and
> shouldn't be duplicated here. An accessor function that takes an
> Asterisk format code and returns the RTP payload type from that table
> would provide what is needed here.

Do you want me to modify main/rtp.c or does such an accessor function already
exist? (Sorry if I missed it, I was looking for that before copying the

I went through the code and rewrote the following company names:
1) Cisco
2) Linksys
3) Snom
4) Barix
-> FreeSWITCH was the only one that was already correct. At least that's how
the name is presented on www.freeswitch.org

Do you agree with how they are written?

By: Andy Brodmann (macbrody) 2008-02-09 02:15:22.000-0600

I'd be glad if someone of digium or oej could answer the above question concerning main/rtp.c before I head on.


By: Olle Johansson (oej) 2008-02-13 06:08:01.000-0600

yes, add that function to rtp.c


By: Kristian Kielhofner (krisk84) 2008-02-27 09:04:59.000-0600

Oh what is that they used to say...  Bueller?  Bueller?

By: dimitripietro (dimitripietro) 2008-04-28 21:35:37

What about Polycom phone, they support multicast paging ?

By: snuffy (snuffy) 2008-07-26 21:07:23

any updates macbrody?

By: Andy Brodmann (macbrody) 2008-08-07 03:10:45

I am working on a simplified version of rtppage which
will free me from the locking problems, caused by my
config file handling stuff.

update ready within one week.

By: Andy Brodmann (macbrody) 2008-08-10 17:06:05

the latest upload (app_rtppage-20080810.c) is a
stripped down version of the original application.
tested against svn @ 2008-08-10.

It comes without config file. All parameters can
be passed in the dialplan.

All critical code was either fixed or removed to
keep the app as small as possible instead of big
and bulky.

Why not using more/all codecs:
RTP Multicast Streaming does by definition exclude
further signalling. This means any codec that does
not have a Payload Type assigned in
cannot be used.


By: Andy Brodmann (macbrody) 2008-08-10 17:22:29

fixed: (app_rtppage-20080810-2.c)
check if the user entered an invalid tos and display a warning where appropriate.

By: Andy Brodmann (macbrody) 2008-08-10 17:25:53

For those working with asterisk-1.4.x a backport
can be found @ http://www.netconf.ch/asterisk/

By: snuffy (snuffy) 2008-08-10 19:31:17

macbrody I would make a suggestion.
the 'multicast start/stop' comments probably clearer if you remove comment and add a define of  MCAST_STARTCMD 6 and MCAST_STOPCMD 7

By: Leif Madsen (lmadsen) 2008-12-05 10:41:10.000-0600

It seems this code may be really close to being able to go in. Does anyone, (macbrody?) have the ability to move this issue forward?

By: Kristian Kielhofner (krisk84) 2008-12-05 10:58:26.000-0600

Yes, anyone, anyone? Please?

By: Leif Madsen (lmadsen) 2009-02-27 16:18:42.000-0600

Changing status back to new as this issue is now stalled.

By: Andy Brodmann (macbrody) 2009-03-02 16:12:03.000-0600


what in addition to snuffy's suggestion has to be changed for the
code to be accepted?

By: Leif Madsen (lmadsen) 2009-03-02 16:46:02.000-0600

macbrody: basically 2 things:

1) any code changes suggested in the notes (there may just be that one remaining)

2) someone to test the code and verify it is working in a production environment

At that point we can mark the code Ready For Review, and it can go to the reviewboard for a more thorough review. Once anything that comes up in the reviewboard has been addressed, then the code would be ready for merging.


By: Kristian Kielhofner (krisk84) 2009-03-09 13:57:59

We'd be willing to do the final test if someone can address the issues in the notes and sign off on the code.

By: Andy Brodmann (macbrody) 2009-03-09 15:22:37


I'll integrate the suggestions from snuffy and make sure the
code compiles against trunk. This will be done by Thursday night (12 Feb).
But then again we'd need someone from Digium look into it/check it.

Hopefully this time the code is ok; I stripped it down and removed any use of
code or routines that are not publicly documented/explained.

By: Leif Madsen (lmadsen) 2009-03-10 12:12:47

macbrody: once you are happy with your changes, upload them here for initial review and testing, then we can put the patch through reviewboard for a more thorough review by the community -- remember that Asterisk is a community project, so not everything needs to be done by Digium :)

By: Andy Brodmann (macbrody) 2009-03-12 15:52:10

Changes done as requested; comments modified as suggested by snuffy.

I have compiled it against trunk today and tested if the module loads/unloads properly. As I don't have access to any Snom/Linksys or other multicast capable SIP phones at the moment I'd appreciate it if someone could install the module and test it. - The latest version is tested to compile against trunk only.

Meanwhile if someone else could do a first review that would be fine.
only 5 codecs are supported not all as suggested before, reason is explained in http://bugs.digium.com/view.php?id=11797#91266.
the module is not using code out of rtp.c/rtp.h. Remember the multicast stream is not comparable to a channel or anything where signalling takes place and it is unidirectional only. Furthermore couldn't I use the tables there. I would have to place another translation table into it and add a special routine to get this table out again.

By: Andy Brodmann (macbrody) 2009-03-12 15:59:36

I have just noticed that most apps in trunk don't show any information anymore when issuing:

application show app_xxxxxx

There seems to be that the former variables are being move to some sort of
xml style comments.

Does anyone know where this leeds and if/how I should modify the app to comply with whatever changes are going on? - I haven't seen anything on the developer mailing list.

By: snuffy (snuffy) 2009-03-12 17:15:29

There is a change to using XML for application/function documentation for the user. Main reason was to more easily facilitate foreign language descriptions. This was discussed quite a while ago on the -dev list (sorry don't have link)

As you can see in other app_* / func_* it is not too hard to convert over to XML your current descriptions etc.

When it comes to committing to trunk this code it would ideally have the XML documentation.

By: Leif Madsen (lmadsen) 2009-03-12 17:33:57

Can I delete all files prior to app_rtppage-20090312.c?

By: Andy Brodmann (macbrody) 2009-03-12 18:05:56

Imadsen: yes, please remove the old files incl. config file (not used anymore)
I am going to replace the description by xml style within the next hour.

By: Andy Brodmann (macbrody) 2009-03-12 18:58:20

ok, I have replaced the old style documentation with the xml syntax. As I haven't found docs I read the other apps' xml docs. If I made a mistake or misunderstood how it was meant to be please let me know.

By: Leif Madsen (lmadsen) 2009-03-18 07:57:06

I took a look at the documentation, and it looks good to me! Thanks for the patch!

Now, if we can only get some people to test this...

By: dimitripietro (dimitripietro) 2009-03-18 08:40:04

I would like to test it but which endpoints support it ?

By: Andy Brodmann (macbrody) 2009-03-18 11:27:54

Endpoints which have been tested to work with are:

- Snom
- Linksys

.. Barix (non SIP) should work too but have not been tested.

Should you need more info than in the docs to get going just
let me know.

By: Joshua C. Colp (jcolp) 2009-04-13 08:43:36

I've created a branch at http://svn.digium.com/svn/asterisk/team/file/issue11797 to bring this work to completion based on some new things available in trunk.

The multicast RTP paging has now been turned into a module that is available to any developer through the RTP engine API.

I have also created a channel driver that uses this to page much like the attached application does. This was done so it could transparently be used with the existing Page() application so that mixed environments can work equally the same. That does not mean you have to use the Page application, you can use Dial if you wish.

I would appreciate some testing on this branch.

The format for the dial string is:

MulticastRTP/<type>/<destination>/<control address>

Type can be either basic or linksys
The control address is optional and only used for the linksys type

By: Kristian Kielhofner (krisk84) 2009-04-13 09:19:13

Excellent work Josh.  One question - I've always wanted to go further with this application.  Reading over various RFCs it looks like it should be possible (and fairly "easy") to support multicast RTP with unicast SIP.  It should be as simple as:

c=IN IP4

(taken from RFC 4566)

This should work with just about any SIP phone at the expense of more overhead (managing individual SIP sessions).

Can this be done within this framework?

By: Joshua C. Colp (jcolp) 2009-04-13 09:21:38

It would require some more modifications to the RTP engine and chan_sip but theoretically yes. All the hard stuff has been done.

By: Joshua C. Colp (jcolp) 2009-04-27 09:33:43

Has anyone been able to test this or has any feedback to provide? I would like to get this into the tree.

By: philipp2 (philipp2) 2009-06-23 18:51:16

You might not want to hear it, but the 1.4 backport appears to be working fine with Snom.

By: Digium Subversion (svnbot) 2009-06-25 13:25:25

Repository: asterisk
Revision: 203227

U   trunk/CHANGES
A   trunk/channels/chan_multicast_rtp.c
A   trunk/res/res_rtp_multicast.c

r203227 | file | 2009-06-25 13:25:25 -0500 (Thu, 25 Jun 2009) | 7 lines

Add support for multicast RTP paging.

(closes issue ASTERISK-11265)
Reported by: macbrody

Review: https://reviewboard.asterisk.org/r/270/



By: Digium Subversion (svnbot) 2009-06-25 13:26:23

Repository: asterisk
Revision: 203228

_U  branches/1.6.2/

r203228 | file | 2009-06-25 13:26:22 -0500 (Thu, 25 Jun 2009) | 13 lines

Blocked revisions 203227 via svnmerge

 r203227 | file | 2009-06-25 15:25:24 -0300 (Thu, 25 Jun 2009) | 7 lines
 Add support for multicast RTP paging.
 (closes issue ASTERISK-11265)
 Reported by: macbrody
 Review: https://reviewboard.asterisk.org/r/270/