![]() Everything works without fault in this scenario but as we are subject to various compliance regulations (PCI-DSS and others) I'm not happy having to trust the SBC alone to protect my internal network. I have bypassed the firewall using a simple switch and placed the SBC WAN directly on the internet with a public IP and the LAN into the PBX network. Not all voip providers are fooled by this but It is always best to disable it in your router to be on the safe side.I have taken traces from both LAN and WAN sides of the firewall and submitted them to the provider and they are suggesting the firewall is changing the packets, something Watchguard deny despite my logs showing this port address translation. If your sip client is behind a nat the nat may translate your local port to a different public port and one way audio can occur.īy leaving a local private addr in the sip pkt the voip provider knows you are behind a nat so can ignore the sdp port and wait for the first few pkts of rtp to arrive and then knows the public port these are coming from and sends rtp to this port. This can fool your voip provider into thinking the sip client is not behind a nat so the audio port in your SDP is used by the voip provider for rtp. It works a bit like stun and replaces your private addrs in sip pkts with the public one of your router. ![]() Sip alg is a setting in your gateway router (assuming you are not running pppoe in the MT) These are the ports that the MT is listening on for incoming Invites. As far as I can tell it has nothing to do with the sip entry in service ports. There is a lot of confusion about sip alg. Unfortunately, I have no idea what that is Do I just disable the SIP entry under Service Ports in the Firewall page? ![]() ![]() Sometimes the phone would ring and when the person hits answer, nothing happens, it keeps ringing, or they hear fast busy when they pick up, but the caller still hears ringback.īasically you only want ALG if you have SIP clients behind it that are not configured to work around NAT, and they're talking to other simple SIP endpoints that are also not trying to work around NAT.Ī VoIP technician asked me to to turn off SIP ALG in my RouterBoard RB750. Other times, some endpoints would think they were registered and the server would think they were dead. the SIP gw really did intend for the phone to send its media to a private IP, but the ALG thought it was being helpful by obscuring this in the messages by the time they reached the phones. However, an ALG would see this SIP message telling the phone to use a private IP as the media address, and alter the message to some other IP (the sip gw, or the router itself) and that would break the audio. For instance, our SIP gateway recognized phones behind NAT, and allowed for "short circuit" if two phones on the same virtual PBX wanted to call "extension-to-extension" and it could see they were behind the same NAT, it would direct them to use each other's private IP as the media address. ![]() If there are multiple then things can slowly drift into the unusual. In general, you want one and only one device doing the NAT workaround. (it started the whiteboard for the old MSN messenger client, for instance) Not only that, but the RFC is somewhat open to interpretation (at least that's what the engineers at a couple of different SIP vendors I've spoken with have told me) because the protocol is so generic. SIP ALG is often poorly coded, probably by someone with little understanding of SIP, which is why it can cause issues. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |