[Freeswitch-users] FS as Media Gateway Only
Saeed Ahmed
saeedahmad1981 at gmail.com
Sun May 30 04:21:10 PDT 2010
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 <http://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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100530/3e367fc5/attachment-0001.html
More information about the FreeSWITCH-users
mailing list