[asterisk-dev] [Code Review] Initialize udptl only when dialog negotiates for image media

[Matt Jordan]

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


There is a problem with this patch.  In an initial INVITE consisting only of image media, there may not be a channel associated with the dialog when the SDP is processed.  This code change causes this scenario to fail, as we set the file descriptor associated with UDPTL for the channel when UDPTL is initialized, and no channel exists.

Its still fine that initialize_udptl attempts to do this, but sip_new will also need to do this for those cases where the dialog is created before the channel.

- Matt


On Jan. 16, 2012, 11:04 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1668/
> -----------------------------------------------------------
> 
> (Updated Jan. 16, 2012, 11:04 a.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp, Mark Michelson, Terry Wilson, and schmidts.
> 
> 
> Summary
> -------
> 
> Currently, the udptl object is allocated in one of three places:
> 1) create_addr_from_peer
> 2) sip_alloc
> 3) handle_request_invite
> 
> This typically results in any dialog associated with a peer that supports T.38 having a udptl object (and its associated UDP ports, system resources, etc.) assigned to it.  This includes non-INVITE requests.
> 
> This patch moves the initialization of a dialog's udptl object to either (a) when the media is negotiated for that dialog, or (b) if a control frame is received in chan_sip indicating that the dialog needs to support T.38.  This should result in only those dialogs that are explicitly involved with sending / receiving image media having a udptl object assigned to them.
> 
> 
> This addresses bugs ASTERISK-16698 and ASTERISK-16794.
>     https://issues.asterisk.org/jira/browse/ASTERISK-16698
>     https://issues.asterisk.org/jira/browse/ASTERISK-16794
> 
> 
> Diffs
> -----
> 
>   /branches/1.8/channels/chan_sip.c 350786 
> 
> Diff: https://reviewboard.asterisk.org/r/1668/diff
> 
> 
> Testing
> -------
> 
> Patch passes the udptl tests in the Asterisk Test Suite.  
> 
> [update] - ported the patch to Asterisk 10 and tested with the Test Suite's gateway tests.  All tests passed.
> 
> However, given the complexity and number of ways in which media can be negotiated, additional testing would be appreciated from the open source community.
> 
> 
> Thanks,
> 
> Matt
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120117/b8f2b203/attachment-0001.htm>