----- Original Message ----- > Tim Nelson wrote: > > Greetings- > > Hola, > > > I'm running into an issue as follows, in simplified form: > > > > A remote Asterisk box, when registered/peered via SIP to a central > > server, and makes a call to that central server, is *sometimes* > > authenticated and calls go through properly (via from-internal > > context), and *sometimes* is unauthenticated, and all calls are > > greeted with congestion() via the from-sip-external context. Yes, > > as you can tell, FreePBX is in play here too. > > > > Grabbing captures of a working call vs a non-working call, I'm > > seeing on the working call, the central Asterisk server is > > responding to the INVITE with a 407 Proxy Authentication Needed, > > box responds, call goes through. On the non-working calls, the > > central Asterisk server is responding with a simple 100 Trying, > > then 200 OKs the session as it throws it into from-sip-external > > assuming the box is not authenticated. > > > > So... and pardon my rambling above... why is this the case? In what > > circumstances would Asterisk respond to the same peer differently, > > seemingly at random? > > chan_sip can match to a peer a few different ways: > > 1. The user portion of the From header matches a configured peer in > sip.conf > 2. The received IP address/port matches a configured peer in sip.conf > using "insecure=very" or combination thereof. > > It's possible that you are relying on #1 but not explicitly > overriding > the user portion in the calling Asterisk using fromuser. Without > doing > this the user portion carries caller ID number information, with can > obviously change between calls. > > That's my best guess without "sip set debug on" output for a > non-working > call and the configuration. >
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... 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? --Tim -- _____________________________________________________________________ -- 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
