[Serusers] SER & Asterisk in a non-routed environment

Klaus Darilion klaus.mailinglists at pernau.at
Fri May 28 14:09:12 CEST 2004


You can create a dial plan, e.g. 1111xxx -> costumer 1, 
1112xxx->customer 2, ...

regards,
klaus

Lars wrote:

> thanks for that, i'll give it a try.
> Furthermore question: What if i have another customers network, say 
> 192.168.20.0/24 connected with it's own gw-box running its own instance 
> of ser. How would * on an incoming call know, where to forward it to?
> 
> greeting from germany
> Lars
> 
> Klaus Darilion schrieb:
> 
>> Yes you can do it. There is a multihome feature for ser (to detect 
>> which interface should be used for sending out messages) and you can 
>> use the new "unstable" rtpproxy in bridging mode. Furthermore, you 
>> have to use the nathelper module to rewrite SIP messages (change IP 
>> addresses and ports).
>>
>> I've never used this setup, but as far as I know it should work.
>>
>> To send PSTN calls to the * box, you don't have to register at the * 
>> box. The clients can register at the SIP proxy and the SIP proxy 
>> verifies access rights before sending calls to certain destinations 
>> (like the PSTN gateway). In the other direction, if there is an 
>> incoming call, you can configure * to fordward calls to certain users 
>> (phone numbers) to the sip proxy, which will forward it to the client.
>>
>> So, next step: Try to setup the proxy on the GW, register your clients 
>> at the proxy and try to make calls inside the 192.168.10.0/24 network. 
>> If this works, try to add nathelper and route RTP via the rtpproxy. If 
>> this works to, try to setup bridging into the asterisk network segment.
>>
>> regards,
>> klaus
>>
>> Lars wrote:
>>
>>> Hi serusers,
>>>
>>> after spending 4 days trying to figure out how to set up things using 
>>> SER I am now hoping for help.
>>> The problem is as follows:
>>>
>>> i have a core network (say 192.168.0.0/24) in which the asterisk 
>>> (192.168.0.99) resides.
>>> i have a users network (say 192.168.10.0/24) in which I (the user, 
>>> x-lite) reside. Theres a gw between those to networks with addresses 
>>> 192.168.0.10 and 192.168.10.1.
>>> The big problem: This gateway is not allowed to forward packets. It 
>>> does usermode port-forwarding for required ports, but it has no 
>>> default route and /proc/sys/net/ipv4/ip_forward is set to 0.
>>> The asterisk is working well and i now wanted to be able to place 
>>> calls to other users (currently one directly connected grandstream) 
>>> through the asterisk. First i check out siproxd which almost 
>>> immediately worked as desired, but i realized, that as soon as the 
>>> 192.168.10.0 network will be populated with more users, i don't want 
>>> the inter-user calls to appear on the asterisk. That's where SER 
>>> comes in. I want it to sit on the gw-box and handle request in the 
>>> users network by itself, but forward requests it cannot handle (e.g. 
>>> pstn) to the asterisk by pretending to be the user himself, as 
>>> siproxd does. Especially i think therefor a user must register at the 
>>> asterisk server through SER which also should notice where to find 
>>> him using usrloc.
>>> I played around with nethelper/rtpproxy but could not even establish 
>>> a sip session, not to mention rtp. I somehow don't understand the way 
>>> ser works, and should handle meet this kind of requirement, so my 
>>> question would be:
>>>
>>> Is 'ser' the tool I'm looking for? And if 'yes', how would it 
>>> basically have to be configured to do what i want. For example one 
>>> problem seems to be, that it forwards packets to the * server from 
>>> it's 192.168.10.1 address which the * box will never know.....
>>>
>>> Thanks a lot
>>>
>>> Lars
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>>
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 




More information about the sr-users mailing list