[asterisk-users] asterisk 1.2 and UDP packet numbering on bridgedchannels (for jitter buffering)?

[Damon Estep]

> 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?