|Summary:||ASTERISK-19304: New feature to send udptl packets directly between both call legs|
|Reporter:||Kristijan Vrban (vrban)||Labels:|
|Date Opened:||2012-02-07 08:56:36.000-0600||Date Closed:||2015-02-28 22:05:27.000-0600|
|Environment:||Attachments:||( 0) t38_p2p_trunk.patch|
|Description:||New feature to send udptl packets directly between both call legs without extrac them. Like p2p for RTP.|
What is missing, a configure option to enable/disable the new feature. It's the first working version to get feedback if this is the correct
|Comments:||By: Kristijan Vrban (vrban) 2012-02-08 04:29:32.483-0600|
for quick test, here the patch
By: Matt Jordan (mjordan) 2015-02-28 22:05:20.279-0600
I'm going to quote [~mmichelson] from the Review Board patch here:
This approach is not going to work for a few reasons:
# This change assumes that both channels are SIP channels. Besides the fact that the assumption is made in a dangerous way, H.323 and Skinny also support UDPTL and would not see the benefits of this change.
# This change places bridging logic into a read callback. Having the reading channel peek across the bridge to get the other channel's private data should be avoided if at all possible.
# This change does not do any sort of compatibility checks between the bridged channels.
I did some digging in the Asterisk trunk code and found that there is an ast_udptl_bridge() function already defined in udptl.c. It appears to do what the goal of this patch is, plus it adds necessary checks for compatibility and other possible reasons why the bridge might fail. The problem is that there is no code that actually uses ast_udptl_bridge() in Asterisk trunk. I think the proper approach to this change is to add appropriate calls to ast_udptl_bridge() where they should go. I think the way to go is to change the .bridge callbacks in UDPTL-capable channel drivers to point to a bridge function which can then call into ast_rtp_instance_bridge() or into ast_udptl_bridge() depending on the type of media being bridged.
Since this patch is not appropriate for inclusion, I'm going to close this issue out as "Won't Fix".