[asterisk-dev] [Code Review] Add ability to set an alternate source for RTP media. Helps in SIP glare situations.

[Mark Michelson]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.digium.com/r/252/#review786
-----------------------------------------------------------


I believe I may know where the small audio delay that I experienced is coming from. It happens because Asterisk B will wait between 0.1 and 2 seconds to re-send its REINVITE to A, and A will wait between 2.1 and 4 seconds to re-send its REINVITE to B if the REINVITEs had "glared" earlier. It is likely this gap between retransmission of REINVITEs where audio is not heard.


- Mark


On 2009-05-19 15:00:31, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/252/
> -----------------------------------------------------------
> 
> (Updated 2009-05-19 15:00:31)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> For a description of the problem, see this: http://lists.digium.com/pipermail/asterisk-dev/2009-May/038348.html
> 
> This patch implements a way to let the RTP stack know that there may be a potential alternate source for media. The alterations to RTP are:
> 
> * new function ast_rtp_set_altpeer to set what the alternate media source may be.
> * new sockaddr_in structures inside the ast_rtp and ast_rtcp structures to hold these alternate sources.
> * ast_rtp_read and ast_rtcp_read have been updated to expect media from these alternate sources.
> 
> The alterations to chan_sip are:
> 
> * new function get_ip_and_port_from_sdp to get the remote IP address and port for audio/video streams from the SDP
> * When we are going to respond to a REINVITE with a 491, we call get_ip_and_port_from_sdp, followed by ast_rtp_set_altpeer so that the
>   RTP stack will not react incorrectly when it receives media from this alternate source.
> 
> Please see the "Testing Done" section for some code review details.
> 
> 
> Diffs
> -----
> 
>   /branches/1.4/channels/chan_sip.c 194872 
>   /branches/1.4/include/asterisk/rtp.h 194872 
>   /branches/1.4/main/rtp.c 194872 
> 
> Diff: http://reviewboard.digium.com/r/252/diff
> 
> 
> Testing
> -------
> 
> I tested by setting up phones and Asterisk boxes as shown in the first diagram in the link I printed in the "Description."
> 
> I found that in REINVITE glare situations, I always successfully had two-way audio. There was a slight catch, though. Usually there would be about a 0.5-1 second gap between when the callee answered the phone and when the caller was able to hear the callee's audio. I have not yet been able to track this odd behavior down. So, in addition to making sure that what I have presented here looks reasonable, if any reviewers might be able to point out what potentially is causing the short delay upon answering the calls, please speak up.
> 
> 
> Thanks,
> 
> Mark
> 
>