| Summary: | ASTERISK-08216: [patch] Packet2Packet bridge incompatible with STUN packets processing | ||
| Reporter: | phsultan (phsultan) | Labels: | |
| Date Opened: | 2006-11-30 05:32:35.000-0600 | Date Closed: | 2006-11-30 15:23:07.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_gtalk |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| 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. ****** ADDITIONAL INFORMATION ****** 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! | ||