[asterisk-dev] chan_sip SIP Authentication

Klaus Darilion klaus.mailinglists at pernau.at
Wed Jan 28 10:49:21 CST 2009



Jesus Rodriguez schrieb:
> Hi Olle,
> 
> 
>>>> 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?
> 
> 
> Please, can you explain a little bit more why you need To: or RPID for  
> routing decisions? I don't fully understand it :-/

Example: An enterprise has 3 phone numbers.
+4311111
+4322222
+4333333

The enterprise uses an Asterisk server which registers with the trunking 
provider to receive incoming calls. You do not want the Asterisk server 
to register for each number - Asterisk registers only once and the 
trunking provider maps all these numbers (or more) to the single 
registration.

Usually SIP routing is based on the RURI. But in this case, the RURI 
received by Asterisk is usually the Contact URI of the REGISTER.

Thus - how does Asterisk find out the originally called number?

A Workaround is to put the originally called number in the To header - 
but this is ugly as To based routing it is against all RFCs.

regards
klaus

> 
> Furthermore, To header is for destination and is always present but  
> RPID/PAI makes reference to source information and you don't know if  
> they will exist.

AFAIK RPID can be used ofr caller and callee, but is obsolete anyway.



More information about the asterisk-dev mailing list