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.
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).
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.
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.
T.
