+1 for path support by default

Some other random preliminary thoughts:

• Is there any reason for NATDETECT to precede retransmission processing? Also, AFAIK Contact header is not (normally?) present in CANCELs so it doesn't need to precede CANCEL processing either. If my hypotheses are correct, moving it after retransmission checks could save a few processing cycles?
• If I'm not mistaken, the default kamailio configuration will always reject auths for methods where From can be set to anonymous. Perhaps it would make sense to enable bit 2 in the flags for auth_check, or provide a commented line with the option for the deployer to enable at will.
• Provide a preprocessor-style option to instruct rtpengine and/or rtpproxy to engage for all calls, regardless of nat detection. This might overcomplicate things a little, however.
• For stateless replies in REQINIT, document that force_rport() might have to be called, since these are sent out before the NATDETECT route
• In the NATDETECT route, force_rport() is set unconditionally if nat is enabled in the configuration. Is there any reason for this? Wouldn't it make more sense for force_rport() to be run only if the nat tests indicate that a request has been NATted?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.