[asterisk-dev] chan_sip SIP Authentication

Johansson Olle E oej at edvina.net
Wed Jan 28 06:57:55 CST 2009


28 jan 2009 kl. 13.45 skrev Philipp Kempgen:

> Johansson Olle E schrieb:
>> The problem arises since you use phone numbers as identifiers for the
>> users. This is not a good thing (TM) and should be avoided. The
>> dialplan is where you route phone numbers. Devices
>
> Or users ...
>
>> should have device
>> names that you address in the dialplan on the extension that is
>> supposed to connect to one or several devices.
>
> While that is very clear in traditional telephony it's not in
> VoIP. SIP URI are by no means limited to numeric usernames
> (/extensions).
>
> So what would you recommend as the proper SIP way:
>
> 123 => {
> 	Dial(SIP/mac-00-04-13-00-00-01-line-1);
> }
> Isn't it the SIP registrar and also the network stack that
> should figure out where that SIP user/device actually lives?
Absolutely. And the phone number has nothing to do with that.

>
>
> philipp => {
> 	Dial(SIP/philipp);
> }
> There's no need for numeric extensions in SIP (and Jabber for that
> matter).
>
> 123 => {
> 	Dial(SIP/philipp);
> }
> This is what you'd prefer I think.
>
> Unfortunately Asterisk does not support multiple SIP registrations
> (resources in Jabber terms).
That's a legacy from the PBX architecture. Forks should happen in the  
PBX,
not in the channel driver.
>
>
> So what would be the proper way to implement something like
> the following in Asterisk:
> alias => {
> 	Dial(XMPP/philipp);
dial(XMPP/philippwork&XMPP/philipphome)
I don't know how the jabber channels address a resource - that's  
something for Philippe to answer :-)
>
>>

>> If we go ahead and change matching order, I'm afraid it will break
>> backwards compatibility and stop many systems from working properly.
>> We don't want that.
>
> Definitely not. But as long as it's configurable and off by default
> it doesn't break backwards compatibility.

Well, thinking about it, it would be hard to do in trunk since we  
already match on name
for a peer first... But it's only code, anything can happen :-)

/O



More information about the asterisk-dev mailing list