| Summary: | ASTERISK-08417: [patch] canreinvite = nonat does not cause packet2packet bridge | ||
| Reporter: | Matthew Nicholson (mnicholson) | Labels: | |
| Date Opened: | 2006-12-21 17:49:10.000-0600 | Date Closed: | 2007-01-10 23:21:25.000-0600 |
| Priority: | Minor | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ( 0) nonat.diff | |
| Description: | The sip_get_rtp_peer function (pointed to by rtp->get_rtp_info) does not check for NAT before instructing the RTP stack to do a native bridge. chan_sip has an option to disable re-INVITES if a NAT is present. Currently if the canreinvite=nonat option set, the re-INVITE operation does not take place (AFAIK, sip_set_rtp_peer (pointed to by rtp->set_rtp_peer) detects the nonat option and the NAT and returns early), but the RTP stack still attempts a native bridge. The attached patch fixes the issue. By having sip_get_rtp_peer check for NAT and return AST_RTP_TRY_PARTIAL if one is found and the nonat option is set. This causes the RTP stack to try a packet2packet bridge. ****** ADDITIONAL INFORMATION ****** This bug/situation may occur in other channels that use packet2packet bridging, I didn't check. | ||
| Comments: | By: Matthew Nicholson (mnicholson) 2006-12-21 18:21:09.000-0600 Also I did not look at the vrtp stream. By: Joshua C. Colp (jcolp) 2007-01-10 23:21:25.000-0600 Fixed in 1.4 as of revision 50466 and trunk as of revision 50467. If not grab me via one of the myriad of ways. Peace! | ||