search for: syrex

...order: ip rule add from 196.33.248.0/24 to 196.33.248.0/24 table main ip rule add from 196.33.248.0/24 table ISP2 Everything works but 196.33.248.0/24 can''t connect to fire as fire is loading the rule pointing at ISP2 first... Regards David Herselman (Executive Proprietor) -=*> Syrex Intranets <*=- =- 12 Coronation Road http://www.syrex.co.za Sandhurst +27-(0)11-883-2246 Voice 2196 +27-(0)11-884-7945 Fax _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listi...

Hi Rowland, I did enable NTLMv1 to provide necessary support for pppd for PPTP VPN connections and that's working as expected. I however do not find any release notes pertaining to 'winbind use default domain = yes' no longer working on a Samba DC. The Samba man pages appear to detail options which apply to winbindd (https://www.samba.org/samba/docs/man/manpages/winbindd.8.html),

Hi, We have a scenario where inbound calls from an upstream provider (chan_sip) sent downstream (chan_iax2) negotiates only g729 yet RTP media contains g711. Both the upstream and downstream trunks are limited to only offering g729 whilst the initial invite from our upstream provider offers both g711 and g729. Asterisk presumably simply forwards the media from iax2 trunk encapsulation to sip

Hi, We're holding ourselves back from moving to PJSIP as we don't appear to have figured out how to force codec preference in a dial plan. The 'PJSIP Advanced Codec Negotiation' document (https://wiki.asterisk.org/wiki/display/AST/PJSIP+Advanced+Codec+Negotiation) appears to ultimately be what we're after, but we're not comfortable running Asterisk 18 in production just

Hi, I was able to use Unsniff to validate that the incoming 20 byte payloads of audio from the downstream IAX2 trunk was definitely G.729a whilst Asterisk 16.13.0 transcodes to G.711a unnecessarily. Media is confirmed as having been negotiated as g729 on all four streams. Nuance with this call is that it's from a WebRTC client which doesn't transmit any audio, could this be influencing

Hi, I was able to use Unsniff to validate that the incoming 20 byte payloads of audio from the downstream IAX2 trunk was definitely G.729a whilst Asterisk 16.13.0 transcodes to G.711a unnecessarily. Media is confirmed as having been negotiated as g729 on all four streams. Nuance with this call is that it's from a WebRTC client which doesn't transmit any audio, could this be influencing

Hi, We have a scenario where inbound calls from an upstream provider (chan_sip) sent downstream (chan_iax2) negotiates only g729 yet RTP media contains g711. Both the upstream and downstream trunks are limited to only offering g729 whilst the initial invite from our upstream provider offers both g711 and g729. Asterisk presumably simply forwards the media from iax2 trunk encapsulation to sip

Hi everyone, We just upgraded Samba from 4.4.5 to 4.6.5 and appear to be experiencing a problem with authentication, when the RPC domain is not supplied as part of the username. I have two scenarios where this has cropped up: RADIUS authentication using ntlm_auth Apache HTTP using mod_auth_ntlm_winbind RADIUS authentication: We use the freeRADIUS 'mschap' module to provide

Hi, I was able to use Unsniff to validate that the incoming 20 byte payloads of audio from the downstream IAX2 trunk was definitely G.729a whilst Asterisk 16.13.0 transcodes to G.711a unnecessarily. Media is confirmed as having been negotiated as g729 on all four streams. Nuance with this call is that it's from a WebRTC client which doesn't transmit any audio, could this be influencing