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

[Russell Bryant]

> On 2009-05-22 11:31:50, Russell Bryant wrote:
> > /branches/1.4/include/asterisk/rtp.h, lines 130-143
> > <http://reviewboard.digium.com/r/252/diff/2/?file=5275#file5275line130>
> >
> >     Add \since 1.6.3 to the docs here
> 
>  wrote:
>     Hmm, the plan was to add this to all branches, not just trunk. In fact, this review request was made against 1.4.
>     
>     Would \since 1.4.26 make more sense?

Yeah, \since 1.4.26, sorry about that.


- Russell


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


On 2009-05-20 10:48:41, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.digium.com/r/252/
> -----------------------------------------------------------
> 
> (Updated 2009-05-20 10:48:41)
> 
> 
> 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
> 
>