> Damon Estep wrote: > > > http://www.asterisk.org/node/48317 does a nice job of explaining the > > 1.4 jitter buffer, however it raised a question in my mind. > > > > > > > > In 1.2 (and also 1.4), when asterisk bridges 2 SIP channels, are the > > UDP RTP packets renumbered on transmit, or is the original sequence > > number preserved in the UDP header? > > > > > > > > A comment is made on the referenced blog that jitter buffering is best > > implemented at the endpoint, where additional jitter will not be added > > by another IP link. This is logical thinking, but only possible if the > > bridging function in Asterisk preserves the source call leg UDP packet > > numbering in the terminating call LEG UDP RTP packet stream. > > > > > > > > If the effect of the Asterisk SIP to SIP bridge is such that the UDP > > headers are re-created on transmit it is likely that the packet > > sequencing is the order in which Asterisk transmitted the packets, > > which is may not be the order in which the original source UA > > transmitted them due to jitter in the IP link on the first half of the > > bridged call. > > > > > > > > Can anyone provide an authoritative answer on how asterisk sequences > > UDP RTP packets on the transmit leg of a bridged SIP call (known based > > on actual testing or code review)? > > > I can tell you about our extensive tests back when we were on version > 1.0.X Asterisk would take in an RTP stream and then recreate a new one > on exit, putting in a new Sequence Number, and new Timestamp in the RTP > Header. This effectly destroys any chance of efficiently relying on > jitter buffering at the endpoints. From multiple tests over the years > we have come to rely on the best jitter buffer we could devise in > Asterisk regarding SIP-SIP channels. That is we loop the call out to a > ZAP channel and back in, thus turning the call into SIP-ZAP-ZAP-SIP. > The ZAP channels have quite good jitter buffers and they work perfectly > in our configuration. Sure you eat extra T1 channels but we have not > choice. Most of our customers are overseas and the jitter is quite high. >
[Damon Estep] I can see how bridging sip to sip via a zap channel would fix minor jitter issues, since the zap timers are very accurate, however I cannot see how this would correct out of order packets like a true jitter buffer does (without the use of a jitter buffer on the sip-zap bridge). Seems like it would be much simpler and more effective to force sip-sip bridge jitter buffering with jbforce=yes (1.4) At any rate, thanks for the information on the new sequence number in the asterisk sip-sip bridge in 1.0.x. have you done any testing in 1.2 or 1.4 to confirm this is still the case? _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
