[asterisk-dev] The New CDR system

Sergey Okhapkin sos at sokhapkin.dyndns.org
Fri Mar 30 15:32:53 MST 2007


Remember the rule of thumb, XML is not readable/consumable format for both 
human and computer because of huge overhead. Overhead is unacceptable for 
real time data. Only binary data protocol like IAX is the way to go. It 
doesn't matter on which port the server process the information, it processes 
it. The easier the information to understand, the better.

No holy wars please.

On Friday 30 March 2007 18:22, zoachien at securax.org wrote:
> I'm a bit afraid to overload the iax protocol, imho some simple XML
> thing might be better ?
> I feel like the servers already have to process enough information on
> the 4569 port.
>
> (although it might be usefull for some people of course - softphones
> could for example get AOC like this.)
>
> Zoa,
>
> Russell Bryant wrote:
> > Steve Edwards wrote:
> >> However, you are mixing "very-real-time" traffic with
> >> "not-quite-so-real-time" traffic. A database query that takes another
> >> 500msec is usually not a show stopper.
> >
> > Um, I don't think so.  I never made any reference to how long the
> > logging itself takes.
> >
> >> Also, IAX is UDP and database connections are (usually?) TCP. How do
> >> you see resolving this?
> >
> > Well, I don't see this as an issue at all.  IAX is just the transport
> > for the event.  Once the event makes it to the remote server, it would
> > be handled just as if the event had originated on the local machine.
> >
> > As far as the concert about reliability goes, the events would be sent
> > as IAX2 full frames, so the reliability is built-in to the protocol
> > itself.  IAX2 handles retransmissions and all that good stuff on full
> > frames, but not on media frames (mini-frames and meta-frames).
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev


More information about the asterisk-dev mailing list