asterisk users - May 2007 - asterisk 1.2 and UDP packet numbering on bridged channels (for jitter buffering)?

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

 

Or maybe there is information I lack that makes this a silly question,
such as where the SIP RTP sequence number is stored in the packet (ie:
not in the UDP header?) :-)

 

Thanks!

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20070508/78576a15/attachment.htm

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.
>  
>
> Or maybe there is information I lack that makes this a silly question, 
> such as where the SIP RTP sequence number is stored in the packet (ie: 
> not in the UDP header?) J
>
>  
>
> Thanks!
>
>------------------------------------------------------------------------
>
>_______________________________________________
>--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
>  
>

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