[asterisk-dev] [Code Review] Add new SIP-specific option to the CHANNEL function to retrieve source RTP address/port. Fix crashes that could happen when getting remote RTP address/port

[Russell Bryant]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/542/#review1733
-----------------------------------------------------------

Ship it!


The code looks good to me, though an automated test would still be nice, as you mentioned.


/trunk/channels/sip/dialplan_functions.c
<https://reviewboard.asterisk.org/r/542/#comment3820>

    remove this debug message


- Russell


On 2010-03-24 09:18:59, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/542/
> -----------------------------------------------------------
> 
> (Updated 2010-03-24 09:18:59)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> This patch accomplishes two objectives:
> 
> 1. It adds a new option to the CHANNEL() function to retrieve RTP source address and port for a given stream.
> 2. It fixes crashes that could occur when attempting to retrieve RTP destination address and port when given a non-existent stream.
> 
> Note that even if I get a "Ship it!" on this code, I'm not necessarily going to commit it until I also have an automated test in place for it. Likely this will be an external test in a separate repo and will be submitted as a separate review.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/sip/dialplan_functions.c 253799 
> 
> Diff: https://reviewboard.asterisk.org/r/542/diff
> 
> 
> Testing
> -------
> 
> Using manager's GetVar action, I retrieved the destination and source RTP audio addresses and ports and verified that they are what I expect. Out of curiosity, I tried to see what would happen if I requested an RTP address/port for a nonexistent stream, such as a video stream during an audio-only call. This is how I found the crash. Now, with my fix in place, there is no crash, and an empty string is returned in such a case.
> 
> 
> Thanks,
> 
> Mark
> 
>