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

Lars ser at lekv.de
Fri May 28 15:12:16 CEST 2004


so after rereading my mail i could have guessed that answer. The detail 
i forgot is: What if a number registered in customer1-net switches to 
customer2-net? Can SER accept a register from a phone and then act as 
that phone and register with the phone's credentials at a parent sip/* 
server with it's own ip address details like siproxd does? That would 
let asterisk know, where to find a certain phone.....



kind regards
Lars

Klaus Darilion schrieb:

> 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