[Freeswitch-users] FS as Media Gateway Only

Sat May 29 13:55:12 PDT 2010

In our implementation only Media servers generate CDRs. No Media session -
no CDR (at least we need exactly this behavior).

However if you need, you can generate CDRs only on Signalling servers I
beleive.

Regards,
Vitalie

2010/5/29 Saeed Ahmed <saeedahmad1981 at gmail.com>

> If i understood correctly, Vitalie solutions is still workable, (although
> what Code mentioned, would be ideal), because from customer side its normal
> to provide multiple IPs or in most cases a whole subnet range, and call can
> come any IP from theatrange, a good example is Arbinet.
>
> Commercial SBCs like nextone support it.
>
> Vitalie, i've a concern that in your solution how would we deal with cdrs?
>
> Thanks
>
> On Fri, May 28, 2010 at 1:31 PM, David Ponzone <david.ponzone at gmail.com>wrote:
>
>> Code,
>>
>> you're totally right.
>> In this model (FS), the media server will also be in the SIP Path.
>> That's why I answered in the first place that this was not achievable with
>> FS, because your idea was more a Kamaillo/RTPProxy setup, where the
>> mediaserver only does RTP with the endpoints, and is not in the SIP path at
>> all:
>>
>> inbound <--------SIP------ SIP Server/Proxy ------------SIP------->
>> Carrier
>>                                                   |
>>              <---------RTP------ MediaServer--------RTP--------------->
>>
>>
>> Verizon Business (in Europe at least) has a such infrastrucutre: OpenSER
>> for the SIP part, and Nortel GWs for the RTP.
>> This way, they just give me the IPs of their OpenSER servers, and they can
>> deploy as many media servers as they need without telling us (of course, we
>> dont filter that).
>>
>> I don't know how this is implemented in Kamaillo/OpenSER but perhaps, for
>> a nice bounty, that would be something possible in FS.
>>
>> David Ponzone  Direction Technique
>>  email: david.ponzone at ipeva.fr
>> tel:      01 74 03 18 97
>> gsm:   06 66 98 76 34
>>
>> Service Client IPeva
>> tel:      0811 46 26 26
>> www.ipeva.fr  -   www.ipeva-studio.com
>>
>> *Ce message et toutes les pièces jointes sont confidentiels et établis à
>> l'intention exclusive de ses destinataires. Toute utilisation ou diffusion
>> non autorisée est interdite. Tout message électronique est susceptible
>> d'altération. **IPeva** décline toute responsabilité au titre de ce
>> message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas
>> destinataire de ce message, merci de le détruire immédiatement et d'avertir
>> l'expéditeur.*
>> *
>> *
>>
>>
>>
>> Le 28/05/2010 à 05:34, Code Ghar a écrit :
>>
>> 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
>>>
>>>
>> _______________________________________________
>> 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
>>
>>
>
> _______________________________________________
> 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/20100529/c198edc3/attachment.html 