Re: [Iaxclient-devel] Conferencing In IAX Clients

[John T. <jt...@lo...>]

At 7:32 PM -0500 1/9/04, Steve Kann wrote:
>Steven Sokol wrote:
>
>>Greetings,
>>
>>Do any of the existing IAX user agents support conferencing?  What seems
>>to be the most logical way to accomplish conferencing in iaxClient?
>>Does the Asterisk server act as the point of conference (ala MeetMe) or
>>is there a strait-forward way to make the client bridge multiple voice
>>streams?  Other than tossing everyone into a MeetMe, I can't think of a
>>good way to establish a conference -- especially when you take into
>>consideration the possibility of multiple codecs in the mix.
>>
>>Any thoughts?  Am I missing anything?
>>
>
>We currently are using iaxclients for a conference, and we do it on 
>the server (although we do not use meetme, we use app_conference, 
>which is in CVS with iaxclient on sf.net; it does need updating).
>
>If you wanted to mix incoming calls like this in iaxclient, you 
>could use a similar approach to that taken by app_conference, but it 
>could be CPU intensive to do this for a large conference in 
>uncontrolled client environments.

Apologies if this starts to go off-topic, but I don't understand why 
you'd use app_conference in the first place, as app_meetme seems to 
cover much of the same functionality.

As to SteveK's original question: why not just fork multiple copies 
of the iax agent and send the audio stream back to the original agent 
instance in a muxed manner?  Multiple codecs shouldn't matter; if you 
can accept the codec of the caller, then everything is fine.  The 
only limitation would start to be horsepower on your box and 
(probably sooner) bandwidth at whatever bottleneck was upstream from 
you.

Here's what I would see as one of two options:

First part of call scenario:

A -> B

If our Asterisk server is doing the right thing, then A will call B 
and the audio stream will flow between A and B, and only the setup 
will go through our (unshown) Asterisk server.

Now, let's say C calls B:

A -> B
      ^
      |
      C

Ideally, we'd like to have our Asterisk server again just set up the 
call, and the audio data would create a second call on B's machine. 
B would answer the call, hit the mythical "conference" button, and C 
and B and A would now all be chatting at the same time.  Bandwidth to 
B's computer would more-or-less double, since he's now sending 
traffic to two different destinations: B and A.

In the conference situation, wouldn't there simply be two instances 
of a call happening with the audio shared back to the "primary" 
instance of the call?  Is this supported in the library?  Sorry, I'm 
not enough of a coder to peek in there and see.

Additonal channels would come into this conference in the same 
fashion, where for every call to B there would be an incremental 
increase in bandwidth for B.  I'm uncertain how one would force this 
to be a single stream between * and B without using MeetMe.  I 
suppose this would be a "native bridge transfer" or something.

JT