In response to the SIP and NAT discussion, I have updated the ticket on the subject that seemed to be getting the most attention: #104. There are enough clueful people here that perhaps someone can come up with a patch that handles NAT in the elegant way that I describe in the bugnotes, as I am but a mere integrator who has limited C skills. In the absence of such a patch being offered, we await William Waites' patch and disclaimer which will at least be more sufficient than the current externip= method. Those with an interest in the discussion of how Asterisk should handle being put behind a NAT should direct their attention to: http://bugs.digium.com/bug_view_page.php?bug_id=0000104 JT
...and to solve another problem, there's my suggestion on support for outbound SIP proxy. http://bugs.digium.com/bug_view_page.php?bug_id=0000359 There are corporate networks that use a "SIP proxy proxy" as an ALG, application layer gateway, for all outbound and inbound SIP traffic in the DMZ. This should work in conjunction with netmask/STUN - if host does not belong to my network send SIP transaction to outbound proxy else send SIP transaction to host done This cleverness may cause problems with inside networks consisting of several networks with different netmasks and complicated routing... I believe outbound proxy should be configured on a host by host basis for sip clients/peers as well as an "default" outbound proxy to use in other situations. In order to support SIP URL dialling, we have to use a netmask/STUN solution to sort out if the SIP proxy we're trying to reach is ourself, someone on the inside or someone on the outside of our NAT. /O
Maybe Matching Threads
- [patch] allow the transfer keys from app_dial's't' and 'T' and hangup key 'H' to be configured via features.conf
- ChanSpy by anthm and more...
- [patch] allow the transfer keys from app_dial's 't' and 'T' and hangup key 'H' to be configured via features.conf
- MGCP: Current CVS works for you?
- *** Asterisk Sunday News: The SIP NAT Special