Klaus Darilion wrote:
>
>
> Eric Chamberlain schrieb:
>>
>> On Oct 7, 2009, at 12:09 AM, Klaus Darilion wrote:
>>
>>>
>>>
>>> Eric Chamberlain schrieb:
>>>> Hello,
>>>> We'd like to move registration to upstream VoIP providers off of
>>>> Asterisk and on to something that can be updated dynamically and
>>>> maintained in a database. Could the python pjsip module be used to
>>>> perform registrations on behalf of the Asterisk server (contact
>>>> info would point to the Asterisk server)? If so, can it scale up
>>>> and handle hundreds or thousands of registrations at a time?
>>>
>>> Of course this only works if your upstream VoIP provider accepts the
>>> value in the contact header. Many providers (me too) do ignore
>>> Contact completely and use IP:port from where the request was
>>> received instead.
>>>
>>
>> Klaus,
>>
>> Interesting point. How does your or other providers' configurations
>> handle multiple registrations from the same IP:port? Multiple users
>> behind a firewall for example? If you ignore the contact, how does
>> the registering device know where to route an inbound call?
>
> Hi Eric!
>
> I was bit too less verbose. The provided contact will be stored by the
> proxy, and during in incoming call, the RURI of the INVITE will be set
> to the provided contact. However, the INVITE will not be sent to the
> URI in the RURI, but to the IP:port from which the registration was
> performed.
>
> For example in Kamailio (Openser) this is done by storing both data
> during registration.
>
> location table (which holds the registered clients):
>
> AoR | Contact | received_from
> -------------+-------------------------+----------------
> aaa at domain | sip:192.168.0.1;line=1 | 1.2.3.4:5060
> bbb at domain | sip:192.168.0.1;line=2 | 1.2.3.4:5060
>
>
> Thus, an incoming call to aaa at domain will be sent to 1.2.3.4:5060,
> with request line containing: INVITE sip:192.168.0.1;line=1
>
> In Kamailio, this can be activated by using fix_nated_register()
> before calling save("location").
>
> If you do not sending back symmetrically, but instead using the
> provided contact for routing, you have to validate the contact before
> - for example a malicious user could send a REGISTER with
> Contact: sip:0900666666 at ip.address.ofyour.gateway
> and the proxy will forward the request to its own PSTN gateway instead
> of sending it to the user.
>
> regards
> klaus
>
>
Klaus,
Since you mentioned Kamailo, one may also opt to use it as outbound
proxy for both asterisk and the third party registration app. This way,
all requests to the provider will be coming from the same IP (Kamailo)
for as long as fix_nated_register() is not used. The only downside to
this is that most far-end NAT traversal technique, (probably deployed by
the provider as well) is to send CRLF/CRLF sequence as NAT keep-alive
and will not be relayed by Kamailo to asterisk. But I guess, in the
OP's particular deployment, NAT is not an issue.
Joegen
