[asterisk-dev] chan_sip: configurable peer username in digest authentication

Olle E. Johansson oej at edvina.net
Sat Jan 30 02:20:24 CST 2010


29 jan 2010 kl. 18.23 skrev Pietro Bertera:

> nice idea..
> do you think is a good idea to use the auth parameter in peer configuration?
> 
> example of sip.conf:
> [general]
>  realm=mylocalrealm
>  ....
> 
> [peerName]
>  auth=user:password at remoteRealm ; used for outbound authentication
>  auth=localUser:localPassword at mylocalrealm ;used for inbound authentication
>  ...
> 
> 
> I wonder if using the same auth parameter could add confusion in
> configuration file..
> What do you think?

I don't think we should add more parameters that work both outbound and inbound. I tried to clear up the "secret" by adding remotesecret so we have one secret outbound and one inbound. We should aim to make the configuration more simple! My comments where more along the line of reusing existing code structures, not config parameters.

I dont think the auth= syntax works well for inbound. The realm is either the one set by the realm= parameter or the autorealm. We don't need another setting for realm in a peer. After thinking about it for a while I've come to the conclusion that we should propably call this setting "authuser". We need to check and test carefully so this doesn't break the existing matching or just implement this in the new type of devices we're heading for in trunk. There's already some bad code in chan_sip to match on digest auth user that potentially could mess this up. If we can prove that this code doesn't collide with anything existing in that code path, this patch seems small and simple enough to be committed quickly.

We've had so many issues with the device matching and auth in the past, so I'm very scared for touching the code for existing peer/user device types again - I would prefer starting over with the new device types we're planning to implement. We already have some code from Nick for type=service and we need to build on that and start with the famous architecture overview ;-)

/O


More information about the asterisk-dev mailing list