Tim Nelson wrote:
Thanks Joshua- In this case, we're using SIP registration to peer the remote systems to the 'central system'. In option #1 above, the 'user' portion is always the CID we set for the outbound call, but the actual SIP user is something different like 'site12' for example. So, it would appear #1 is not a match...
Registration just tells the remote system what your IP address/port is for sending calls.
You don't *have* to send CID like you are. You can override using fromuser to ensure that the specific peer is *always* matched and authenticated. CID can be conveyed in an alternate header, like Remote-Party-ID. The options involved for RPID are "sendrpid=yes" on the caller box and "trustrpid=yes" on the receiving box.
That leaves us with option #2. We're using 'qualify=yes' on both sides of the SIP peering. If a peer becomes unreachable (fast UDP state table timeout on a remote firewall for example) as seen by the central system, and an outbound call is made from the remote system, that would mean the call is coming from an unknown IP:port. Would this then make sense Asterisk would simply throw it into the from-sip-external context as an unknown/unauthenticated call? And of course, when the peer *is* registered, and a call is made, Asterisk on the central system allows the call as authenticated due to the source IP/port being known via the registration status?
It's possible, without logs and such it's only a guess. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- New to Asterisk? Join us for a live introductory webinar every Thurs: http://www.asterisk.org/hello asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
