[Asterisk-Users] iax2 wireless and Multicast

[Alexander Lopez]

Asterisk dows not currently support MultiCast.

You may want to look at some applications that where written for Mbone
http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/bryan/index.html

If you can incorporate them into an Asterisk Channel Driver,
These tools would allow you to:

Use Multicast to 'broadcast' from one Asterisk server.

Your Clients could then be either a dedicated application sittng on a PC or other Device, or you could have an Aserisk server convert from MultiCast back into Unitcast and then to any device that Asterisk supports.

Let Me know if you need any help.

Alex
 

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com 
> [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of 
> Francisco Pérez Botella
> Sent: Wednesday, January 04, 2006 7:05 PM
> To: asterisk-users at lists.digium.com
> Subject: Re: [Asterisk-Users] iax2 wireless and Multicast
> 
> El Miércoles, 4 de Enero de 2006 16:06, tim panton escribió:
> > On 4 Jan 2006, at 13:28, Francisco Pérez Botella wrote:
> > > El Miércoles, 4 de Enero de 2006 12:28, tim panton escribió:
> > >> On 3 Jan 2006, at 19:10, Francisco Pérez Botella wrote:
> > >>> Hi.
> > >>>
> > >>>
> > >>> I will have to manage From asterisk to clients IP-phones, so 
> > >>> biefly the idea is to multiplex voip flows in large packets and 
> > >>> multicast them from asterisk/AP to client stations. flows from 
> > >>> client stations to asterisk gateway go unicast. I 
> wonder how iax2 
> > >>> protocol will be good for multiplex
> > >>> (trunk) and multicast ??
> > >>
> > >> Hmm, it won't be easy.
> > >> The IAX protocol is not multicast aware, so it is expecting a 
> > >> single ack to each full frame.  You will have to do 
> quite a bit of 
> > >> work on the IAX implementation for it to do the right 
> thing in that 
> > >> area.
> > >
> > > I see, maybe I could redirect at network layer 
> unicast-->multicast 
> > > addresses/group and give back a "false" single ack at that point.
> > > On the other side (client side). I need some like a 
> "virtual trunk"
> > > where each
> > > station recieves the full frame and "stealth" the payload 
> it needs 
> > > for the
> > > user/phone(s) it serves. I could at client station 
> redirect traffic 
> > > from multicast to unicast interface address and serve the 
> full frame 
> > > to
> > > iax2 at
> > > client station, silently dropping the acks they give back.
> >
> > yes, but you need to ensure that only one client station 
> sends an ack, 
> > or that the server station can cope with multiple acks.
> 
> explained before... send back the ack from AP before 
> multicast it, maybe a check match in iptables and spoof an 
> ack to peers/servers.
> But you point me to another element, Do I need to make belive 
> to peers all the back messages are from same source, Ok no 
> problem, snat in the AP the flows from base stations clients 
> that reply in unicast .
> >
> > >> I'm also not sure I see the advantage of multicast, given that 
> > >> normally phone calls are 1 to 1 connections, (except 
> conferences I 
> > >> suppose).
> > >
> > > That maybe true for wired but wireless in infraestructure mode 
> > > there's a point of distribution (the AP) that even can police and 
> > > pool in a pseudo TDM, I mean all the traffic in the 
> subnet is going 
> > > to pass trought that point
> >
> > Sure, but that isn't any different from any asterisk server 
> connected 
> > to an ethernet (except in speed) (Wasn't the pre-cursor of 
> ethernet a 
> > radio based net in Hawaii ?). You aren't saving very much 
> capacity, as 
> > IAX miniframes have a low overhead. You would probably do better to 
> > run IAX over the lowest level protocol you can get at (i.e. lose IP 
> > and UDP headers and go straight to the packet radio level).
> >
> I'm playing with 802.11 networks can iax2 run over this radio 
> frames natively ??, don't think so...
> but you has pointed the center much of the overhead is in the 
> MAC/PHY layer 800ms what is not comparable to fixed ethernet, 
> so if I have the chance to send less but larger packets 
> capacity grows with similar latencies-delays
> > >> Is it a packet size problem ?
> > >
> > > It's a capacity problem first, it's an avoidance of 
> collisions too.
> > > wireless is a shared medium (radio) and minimizing 
> overhead without 
> > > latency penalty will be important. I think that in a radio system 
> > > broadcast is for free capacity and overhead is not.
> >
> > Yep, but apart from the headers you won't be saving any 
> actual payload 
> > bytes,
> >   unless more than client is listening to the same stream 
> at the same 
> > time.
> ALL the clients are listenning to the same stream, in fact 
> I'm thinking of "duplicated" peer to all base stations (same 
> multicast address)that serve the propper flow to iaxclient 
> application, I mean that only propper users/phones will be 
> configured in a virtual peer that is copied at all the base stations.
> 
> How is going to react this virtual peer to the miniframes 
> intended for an user/number its not configured with him (fail 
> or flag error to peer/Bad bad bad----discard packets will be 
> nice)??? I want to this virtual peer to act as a demultiplexer
> >
> > As for collisions, I see a (nasty) problem that trunking 
> might cause:
> > Many IAX clients use the incoming audio stream as a timing 
> source to 
> > the outgoing one. In a Trunked/multicast situation you'd 
> have all your 
> > clients replying in sync - which would cause collisions, since they 
> > would all reply at once. You would have to impose some delay on the 
> > client side to ensure they didn't. Easier not to trunk I'd say.
> 
> I read that you have to configure the trunk IN BOTH 
> directions if you don't you only has a one direction trunked, 
> maybe if you don't configure to do trunk from base stations 
> to outside you can solve this. I don't know (try) yet, but 
> yes that's a problem I have to deal with.... ummh maybe 
> frottle or some other queue-buffer policing algorithm 
> governed by the AP
> >
> >
> 
> thanks all you for the points. still reading 
> 
> > T.
> >
> >
> > http://www.westhawk.co.uk/
> 
> --
> Francisco J. Pérez Botella
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> Asterisk-Users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>