[Freeswitch-users] FS as Media Gateway Only

[Code Ghar]

Hi Vitalie

Thanks for providing the link and details. If I understood correctly, the
chain of signaling would be Inbound -> FSSIP -> FSRTP -> Outbound (using
names and terms in my original question), while the chain of media would be
Inbound -> FSRTP -> Outbound. This way we can have multiple servers handling
media and minimal servers handling signaling.

Let me clarify a little more my motivation for asking this question in the
first place. I work with telecom carriers on a daily basis and have seen
many different architectures. The first biggest problem is how to load
balance SIP traffic when you are receiving calls, if one server is not
enough. The second biggest problem is handling all RTP, including
transcoding. With this architecture, one or two IPs for signaling can be
handled by most carriers. So you can beef up your hardware for signaling and
depend less on your carrier's ability to load balance traffic for you. If
they can do round-robin or failover for two IPs, you are golden. And then
you can deploy multiple nodes to handle all RTP duties, without having to
concern your carrier about multiple servers and IPs. But there's one thing
still missing. Your outbound carrier still needs to allow traffic from
multiple IPs because now they are dealing with FSRTP instead of FSSIP.

Is there such a solution possible using FS that all signaling, for both
inbound and outbound carriers, can be handled by a couple of FSSIP nodes
(depending on the amount of traffic, maybe a few more) while delegating
media responsibilities to multiple FSRTP nodes? In this situation, SIP IP is
always, say 10.10.10.1 or 10.10.10.2, but the SDP may use media IPs
10.10.10.3, 10.10.10.4, 10.10.10.5, and so on. Almost all carriers I have
seen concern themselves only with which SIP IPs they should allow and don't
care how many or which media IPs they have to deal with. Any ideas on
minimizing signaling IPs while adding more media IPs as required?

I have seen re-invite being used in production where you can just let your
inbound and outbound handle media between them on their own without it going
through your network. But there are circumstances where people might need to
pass media through their own network, chiefly to perform transcoding and
also to handle other interop issues. It is because of this use case,
combined with the need for minimizing signaling IPs, that the original
question was asked.




On Thu, May 27, 2010 at 1:15 AM, Vitalii Colosov <vetali100 at gmail.com>wrote:

> Hi Code,
>
> I have working example doing exactly what you've described.
> One signalling FS bridges incoming call to a set of media servers
> (depending on ip, but you can implement any routing logic including round
> robin) and then transfers media stream after bridging to that media server.
>
> You can achieve this on signalling FS by creating a Lua script that
> contains the following lines:
>
> media_server="my_media_X.mydomain.com"; --to be determined by routing
> logic
> forwarding_session = "sofia/external/"..called_number.."@"..media_server;
> session:setVariable("bypass_media_after_bridge", "true");
> session:setVariable("hangup_after_bridge", "true");
> session:execute("bridge",forwarding_session);
>
> The call will arrive to the selected media server successfully and media
> stream will start bypassing signalling FS after bridge.
>
> You can read the following thread, it describes how you can setup such
> configuration.
>
> http://lists.freeswitch.org/pipermail/freeswitch-users/2010-March/055231.html
>
> I think it will fit your needs.
>
> Regards,
> Vitalie
>
>
> 2010/5/27 Code Ghar <codeghar at gmail.com>
>
>> Is it possible -- and are there any case studies, practical experience,
>> etc -- on deploying FreeSWITCH (FS) in this architecture: one server (FSSIP)
>> handles SIP signaling only, and multiple servers (FSRTP1, FSRTP2, ...,
>> FSRTPn) handle all media responsibilities? So when a call comes in, the SDP
>> contains IP of, say FSRTP1, as media handler. For this to work, FSSIP would
>> request FSRTPx for media resources for each new call and add its IP and port
>> in SDP. The media servers/gateways would play IVR, etc.; collect DTMF and
>> forward as appropriate to FSSIP; perform transcoding; etc.; all while FSSIP
>> only deals with signaling. This way multiple servers could be deployed to
>> handle media responsibilities and only a handful would be required for
>> signaling. In future if there's a greater need for transcoding, etc. all you
>> need to do is deploy a media server and not have to add servers for
>> signaling.
>>
>> This idea came to me because I have come across two proprietary
>> applications that do it this way. They have a SIP component and a media
>> component. You can run both on the same physical machine or you can separate
>> them out into multiple machines.
>>
>> Another way for this could be to integrate FS as a media component to
>> another application's SIP component. A mix-and-match, so to speak.
>>
>> On the flip side, deploy FS as a SIP server and use media capabilities of
>> some other hardware or software application. For example, FS handles
>> signaling and use dedicated hardware for media. A good example of this is
>> illustrated (somewhat) by an image on Sangoma's website:
>> http://www.sangoma.com/assets/images/content/transcoding_diagram.jpg.
>> Look at the "pooled transcoding".
>>
>> Is FS even designed to be this modular? If so, how can the aforementioned
>> scenario(s) be achieved?
>>
>> _______________________________________________
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100527/7c4db7ce/attachment.html