[asterisk-dev] [patch] IAX2 Native Bridge enhancements

Tim Davies tim at opensystems.net.au
Wed Jul 19 17:55:40 MST 2006


Hi all,

Here is a patch I have been playing with which attempts to increase the
success rate of a native bridge.  It deals with multiple intermediate
peers (in my case - softphone <-> home <-> work <-> VoIP provider).  It
also allows retries of the native bridge in certain circumstances.

Here's a summary of what I've done (I hope I've included it all):

- Shift the media-only bridge out of the way.  It was using the
"transfer" host, which is fine until you need to try a subsequent
transfer.  This involved creating a "media" host and associated
send_command_media function, as well as "if" conditions all over the place.
- Add the transferid to all transfer packets.  Not strictly necessary in
all cases, except where needed to resolve which transfer the peer is
dealing with.  It could also help with packet injection attacks, but
breaks backwards compatibility.  All received transfer packets are
compared to the current transferid and ignored if they don't match.
- Allow the peer to retry a transfer later (when a "collision" occurs
with a transfer request from an adjacent peer).  The "collision" is
resolved by who has the higher transferid.
- Changed some of the logic, especially regarding the TXREJ.  A peer may
be doing two independent transfers initiated by the adjacent hosts, or
it may be doing a transfer initiated by itself.  It uses transferids of
the bridgepeer to determine what to do.
- A few small things: like if a channel has been media-only released, it
will always send transfer packets to the media host, and will only try a
media transfer (not a full transfer).  Also when a TXCNT is received, we
set the transfer host to its source address, and send the TXACC back
(like in libiax).

I think that is it.  I wrote it a few weeks ago, so I might have missed
something...

I guess this would need to go into libiax as well, and I have noticed
that libiax has a few differences already (like some packet payloads
differ etc).

It would also need a lot of testing, if it is deemed a worthy solution.

Cheers,

Tim.






-------------- next part --------------
A non-text attachment was scrubbed...
Name: chan_iax2.diff
Type: text/x-patch
Size: 25615 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20060719/9ceaa820/chan_iax2.bin


More information about the asterisk-dev mailing list