[VoiceOps] Preventing random SIP connections to handsets
Matthew Crocker
matthew at corp.crocker.com
Fri Nov 20 15:31:50 EST 2015
> On Nov 20, 2015, at 3:27 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
>
> On 11/20/2015 03:23 PM, Carlos Alvarez wrote:
>
>> That's the default for all the handsets, I believe. There are various
>> options such as "accept only from proxy" or "only from registrar," but
>> like I said it varies so it could be more challenging to employ that.
>> Also in our limited testing it seems like it may not have had the
>> intended effect. Possibly because NAT hides the original IP, but I
>> don't know that for sure.
>
> Any properly standards-compliant registrar will send a Request URI on incoming INVITEs that is equivalent to the Contact binding provided by the phone originally. It can choose to send that INVITE to a network and transport-layer destination that is different to the network and transport-reachability in the contact provided by the handset, i.e. for far-end NAT traversal, but the integrity of the RURI should not be compromised.
>
>> Most phones also have an option to force auth for incoming invites,
>> which we have not tested yet.
>
> I don't think you want that. SIP servers and registrars will certainly definitely expect the registrant to trust them. You can certainly configure Asterisk per se to answer 401/407 challenges from the phone with digest credentials, but that's not a very simple or interchangeable solution.
>
Broadworks handles the 401 UNAUTHORIZED with nonce fine from a Polycom. It will resend the INVITE with the authentication credentials
> -- Alex
>
> --
> Alex Balashov | Principal | Evariste Systems LLC
> 303 Perimeter Center North, Suite 300
> Atlanta, GA 30346
> United States
>
> Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
More information about the VoiceOps
mailing list