2007/12/24, Kristian Kielhofner <<a href="mailto:kristian.kielhofner@gmail.com">kristian.kielhofner@gmail.com</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Dec 24, 2007 5:59 AM, Andreas Brodmann <<a href="mailto:andreas.brodmann@gmail.com">andreas.brodmann@gmail.com</a>> wrote:<br>><br>> I am currently working on a dialplan app that does just about that.<br>>
<br>> If you could provide me specs/info about how your phones<br>> expect the data (codec, packetization time) etc, I'll try to keep the<br>> app as generic as possible.<br>><br>> The linksys phones do expect a start/stop signal to accept this
<br>> paging feature as far as I found out by capturing traffic. Unfortunately<br>> Linksys didn't bother letting me have the data/information on how<br>> these packets have to be formated.<br>><br>> The Cisco 79xx series phones do have a similar feature. You do have
<br>> to authenticate against each phone's internal webserver though to<br>> have them listen to your multicast traffic.<br>><br>> If anyone has information about similar devices, be it phones or<br>> automation systems like the
<a href="http://barix.com">barix.com</a> series devices, which can<br>> handle rtp streams, please let me know.<br>><br>> -Andreas<br>><br><br>Andreas,<br><br> The possibility of app_page enhancements and (maybe) a Page
<br>pseudo-channel intrigues me...<br><br>-- It would be simpler to mix/match multiple device support. For<br>instance, you could build a page command line as follows:<br><br>exten => page,1,Page(Page/group1&Page/group2&Page/group3&SIP/105&Zap/4)
<br><br>where page.conf could look like:<br><br>[group1]<br>method = multicast_rtp ; SNOM style RTP spray<br>address = <a href="http://233.64.133.10:7000/1">233.64.133.10:7000/1</a> ; (IP:port/ttl)<br><br>[group2]<br>method = unicast_rtp ; unicast INVITEs to each recipient with
<br>multicast address in SDP for media (c=) - RFC compliant but a little<br>more work for Asterisk<br>member => SIP/polycom1<br>member => SIP/grandstream1<br>member => SIP/generic1<br><br>[group3]<br>method = linksys_marker ; whatever they need, some variation of SNOM
<br>member => SIP/linksys1<br>member => SIP/linksys2<br><br> This way you could page multiple SIP device types using entries from<br>page.conf while specifying additional technologies on the command<br>line. There would be no reason why you couldn't specify additional
<br>methods that didn't use SIP at all - you could have methods for any<br>channel type in page.conf. Ideally, you would only have to mix audio<br>once for each stream type.<br><br> This would be awesome. Now the real question. Is it practical?
<br>Would we need to rewrite Asterisk to support it? ;) Probably not, but<br>these are the things I'd like to address before we head down this<br>road.</blockquote><div><br>I have a working prototype for the group1 stuff. group3 isn't much additional
<br>work. Haven't looked at group2 style in depth yet. Could you test it with<br>the snoms, if I send you the app?<br>(it's just copying it into the 1.4.x source tree and recompile<br>asterisk from scratch).<br><br>
-Andreas<br></div><br></div>