25 Aug
2004
25 Aug
'04
6:45 p.m.
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