[Asterisk-Users] iax2 wireless and Multicast

[Francisco Pérez Botella]

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