Eric Chamberlain schrieb:
>
> On Oct 7, 2009, at 8:59 AM, 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,
>
> Thanks for the clarification. It sounds like the most compatible
> solution would be to run our pjsip code on the Asterisk box, so that the
> port and IP addresses would match and Asterisk could answer the inbound
> INVITEs.
I would just ask the provider if he allows third-pary registration, or
just test it (e.g. using sipsak) - of course providers can change the
setup and then it wont work anymore.
You could also try Joegen's approach, routing all the traffic via a SIP
proxy, which acts like some kind of egress/ingress proxy (some call it
SBC), e.g:
Asterisk--
\
-------Kamailio -------- Provider
-------SIP Proxy
/
pjsip----
reg-clien
As registration-contact you provide the IP:port of the Kamailio proxy.
Then, the provider will route all requests back to Kamailio and then you
can forward the request to Asterisk.
regards
klaus
