On Oct 8, 2009, at 1:35 AM, Klaus Darilion wrote:
>
>
> 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.
>
Klaus & Joegen,
Thank you for the input. I'll take a look at the sip proxy approach.
--
Eric
