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
