| Summary: | ASTERISK-08134: Reinvite is using local IP of NATed device | ||
| Reporter: | Marcel Barbulescu (marcelbarbulescu) | Labels: | |
| Date Opened: | 2006-11-14 18:06:25.000-0600 | Date Closed: | 2006-11-14 22:48:10.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/General |
| Versions: | Frequency of Occurrence | ||
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Setup: - one phone with public IP, nat=no, canreinvite=yes - one phone with local IP using NAT, nat=yes, canreinvite=no The first phone calls the second, the second answer and reports its local IP in the SDP for RTP audio. The first phone is reinvited with the local IP of the second phone in SDP for RTP audio resulting in broken audio. In order to work canreinvite needs to be set to "no" even for the first device which can do reinvites and they would be very useful when talking with other devices that can do reinvites correctly. ****** ADDITIONAL INFORMATION ****** When asterisk is sending the reinvite to the first phone, it doesn't even know the real RTP IP/port of the NATed device since no RTP packet hit the asterisk box yet. The safest approach would be not to send reinvites at all when one of the sides is behind NAT. If reinvites are sent, they should be sent after the real RTP IP/port were identified, and there is still a chance that the router/firewall of the second device will not accept packets on that specific port from anything but the asterisk box. | ||
| Comments: | By: Joshua C. Colp (jcolp) 2006-11-14 21:47:50.000-0600 I was actually unable to reproduce this. It still went to a Packet2Packet bridge, not a true native bridge (reinvite). Can you edit logger.conf to have debug printed to the console and then set debug 9 and try again? By: Joshua C. Colp (jcolp) 2006-11-14 22:48:10.000-0600 Fixed in 1.4 as of revision 47645 and trunk as of revision 47646. Thanks! | ||