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

[Pietro Bertera]

I restore the topic.

The patch that I submitted does not change the data structures
involved in the peer matching.
I'm using patched chan_sip.c in production environment smoothly.
If it's a good thing i go to upgrade the patch to trunk and write
documentation in chan_sip.conf.sample

Someone says something?

Regards,

Pietro

--
Bertera Pietro
http://www.bertera.it

On Sat, Jan 30, 2010 at 9:20 AM, Olle E. Johansson <oej at edvina.net> wrote:
>
> 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
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>