Summary:ASTERISK-08216: [patch] Packet2Packet bridge incompatible with STUN packets processing
Reporter:phsultan (phsultan)Labels:
Date Opened:2006-11-30 05:32:35.000-0600Date Closed:2006-11-30 15:23:07.000-0600
Versions:Frequency of
Environment:Attachments:( 0) trunk-P2P_gtalk-1.patch
Description:In P2P bridge mode, STUN packets are not processed by Asterisk when a googletalk client to Asterisk call is up, which eventually leads to an unexpected call tear down.

This is because the p2p_callback_enable function steals the fds the RTP/STUN server running on Asterisk should be listening on.

The attached patch solves this issue by doing the following :
- modify the private 'type' string in chan_gtalk.c to make get_proto (in rtp.c) happy
- force Gtalk channels to try a partial bridge, as native bridging is not yet implemented in Gtalk
- prevent the RTP engine from triggering p2p_callback when STUN packets are expected on a channel, just as it is done for DTMF.

Also added a few more debug messages and pointer initializations.


Asterisk and my googletalk client are on the same LAN.

Call setup :
googletalk client -> Asterisk -> SIP device

I guess this is somehow related to ASTERISK-7488, although not really sure.
Comments:By: Joshua C. Colp (jcolp) 2006-11-30 15:23:06.000-0600

Fixed in 1.4 as of revision 48168 and trunk as of revision 48169. Thanks!