At 04:13 PM 8/25/2004, Jesus Rodriguez wrote:
That's like known SBCs work. Before, they sent an OPTIONS packet but last software versions modify the Expire of the 200 OK from REGISTER so is the UA the one that sends a new REGISTER and generates traffic from the internal side every 30 seconds. These REGISTER are not forwarded to the proxy. The SBC keeps a table where saves the "real" REGISTER expire sent to the proxy. This way you don't flood the proxy with all those REGISTER.
Which appears like a questionnable benefit -- I mean it does not seem to make a big difference to me if the extra REGISTER load is put on SER PC or some other PC in front of it... (Not mentioning what other pain SBCs cause -- I just spent a good part of day/night reviewing a network setup in which such an SBC caused real harm.)
I objected several ideas on this mailing list, like ALGs, SBC, and other in-network NAT/SIP patches, so I should perhaps state what I consider a good idea. First it takes good NAT support in end-devices. Creating network-based patches to deal with NAT-incapable devices just creates a great amount of complexity which typically breaks other things. Make clients detect connectivity using STUN, perhaps ICE, let it send keep-alive, implement SIP stack correctly, be symmetric, etc. That's something which is achievable short-term, it is also buyer's responsibility to buy those that get it right.
Long-term removing indeterminism from NATs as in IETF/behave is another important acchitectural activity.
If people ask me how to make SIP/NAT stable right now, regardless of sanity, my preference is to find a good UAC and stick to it. (I have to admit I don't have a specific recommednations -- the capabilities change rapidly fimrware by firmware in a pace I can't follow.) Configure SER to help by reducing registration intervals, using a voice proxy, sending pings.
-jiri