[asterisk-dev] chan_sip SIP Authentication

Johansson Olle E oej at edvina.net
Wed Jan 28 10:47:11 CST 2009

28 jan 2009 kl. 17.39 skrev Klaus Darilion:

> Johansson Olle E schrieb:
>> 28 jan 2009 kl. 15.41 skrev Klaus Darilion:
>>> Johansson Olle E schrieb:
>>>> Well,
>>>> 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 should have  
>>>> device
>>>> names that you address in the dialplan on the extension that is
>>>> supposed to connect to one or several devices.
>>> That's the more elegant version, but then you need a mapping from
>>> number
>>> to user. Thats why I use name=number to avoid this mapping
>> That is why you have hints, Klaus.
> I thought hints are for presence/dialogstate
Hints is the mapping between dialplan extensions and devices, that is  
used, amongst other things,
by the device state subsystem. The name "hint" shows that it was  
created a bit more generic.
>>  memory. I have not changed configuration ...yet.
>>>> This implements a way to
>>>> - register with SIp services
>>>> - get the call back
>>>> - match the proper peer, even if you have five accounts, we will
>>>> match
>>>> the proper peer
>>>> - send the call to the called number (to: header), not using a
>>>> pseudo-
>>>> exten that overrides.
>>> ahh. It took us many yours to tell vendors that To-based routing is
>>> wrong.
>> Oh yes, it is. In theory you should never do that, but...
>> But if you register for a service, the request URI is whatever
>> you register with and can't really be used for any routing decisions
>> in a b2bua.
>> For a simple phone, it doesnt matter. Registration for a trunk  
>> service
>> doesn't really work,
>> which might be a design flaw in SIP.
>> How on earth do you get the requested number without checking To: or
>> RPID?
> Using To: you assume that the To header contains the originally called
> number. But that depends on the setup of the trunking provider.  
> (what if
> the trunking provider uses Asterisk?)
Yes, one has to check with SIP debug first. Always. And if the trunking
provider use Asterisk I've given him a dialstring option to set the to:
header properly - which you of course have seen, since you've read
the docs, right? ;-)

> Yes you are right - SIP trunking is not specified somewhere.
> The trunking provider I use maps the called number in the RURI (thus  
> it
> ignores the userpart in the REGISTER contact but just uses the
> domainpart for routing). Of course this would cause problems if you
> register twice to a trunking provider and has do differ incoming call
> (which is done on the RURI).
Talk about not being SIP-compliant :-) But yes, I've seen that too.
Which shows that something is missing here.
> Isn't there a dedicated P-.... header specified in IMS to signal the
> originally called number?

Maybe. I've used RPID with party=called in some cases.


More information about the asterisk-dev mailing list