[Freeswitch-users] FS as Media Gateway Only

David Ponzone david.ponzone at gmail.com
Sun May 30 11:59:09 PDT 2010


Well, I think I have a way to solve that.

On RS, set a custom SIP header before bridging the call:
X-Route: Supplier-X

And then in the MS dialplan, you just have to route to the right  
gateway according to X-Route.

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 30/05/2010 à 13:21, Saeed Ahmed a écrit :

> Hi,
>
> Actually i am trying to setup the environment to test it real time,  
> but theoretically it looks like that:
>
>                --> MS_1 ------> Supplier (outbound)
> Inbound ---->  RS  --> MS_2 --> Supplier (outbound)
>                --> MS_N ------> Supplier (outbound)
> So what i would like to do, when call hits RS, it will look in  
> database (using curl or lua etc..) for end supplier (outbound) and  
> also selects MS_N (to deal RTP media), so that on a central point  
> (for example RS) we know about real  customer (inbound) and supplier  
> (outbound).
>
> Currently, RS assumes MS_N as outbound supplier because real  
> supplier is behind MS_N. I hope you have got my point.
>
> Thanks
>
> On Sun, May 30, 2010 at 11:45 AM, Vitalii Colosov  
> <vetali100 at gmail.com> wrote:
> Could you please provide an example of what exactly do you think is  
> a problem?
> Because now I don't have any problem with this configuration and I  
> am wondering what is the exact scenario where we cannot use such  
> configuration.
>
> Thank you,
> Vitalie
>
> 2010/5/30 Saeed Ahmed <saeedahmad1981 at gmail.com>
>
> Another point, with following script:
>
> 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);
>
> we can bill the customer (inbound) but supplier (outbound) is behind  
> media_server, so i think it would be a problem to manage ,supplier  
> side for billing and statistics, on signalling server.
>
> On Sat, May 29, 2010 at 10:55 PM, Vitalii Colosov  
> <vetali100 at gmail.com> wrote:
> 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
>
>
>
> _______________________________________________
> 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/20100530/56f6faef/attachment-0001.html 


More information about the FreeSWITCH-users mailing list