[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/
-----------------------------------------------------------

(Updated 2009-05-20 10:48:41.110501)


Review request for Asterisk Developers.


Changes
-------

Addressed Vadim's idea regarding the efficiency of get_ip_and_port_from_sdp. Re-tested and found that everything still appears to be working.


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 (updated)
-----

  /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