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?
I don't think that's possible at the moment. You can still deploy several boxes which will do SIP+RTP but I agree this is not the same thing. David Ponzone Direction Technique email: david.ponzone@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 27/05/2010 à 04:01, Code Ghar a écrit :
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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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.htm... I think it will fit your needs. Regards, Vitalie 2010/5/27 Code Ghar <codeghar@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Vitali, Code, I apologize, I answered too quickly. That's actually a very smart way to do it when you don't have/want a proprietary protocol. It should be possible to distribute the calls evenly by using mod_limit. You can even take the transcoding into account. If you know your media servers will only use G711 to the outside, you can call mod_limit once if the inbound call is G711 also, but you may call mod_limit twice or thrice or more (to be calculated) if the inbound call is G729. This way, your mod_limit figures per media server will reflect the actual load on the server, not only the number of current calls. David Ponzone Direction Technique email: david.ponzone@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 27/05/2010 à 08:15, Vitalii Colosov a écrit :
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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Also consider using a sip proxy to distribute the calls to the cluster of media boxes. This is one of the main reasons we have suffered through SIP so we could have proxies and redirectors based on http =/ On Thu, May 27, 2010 at 1:42 AM, David Ponzone <david.ponzone@gmail.com>wrote:
Vitali, Code,
I apologize, I answered too quickly. That's actually a very smart way to do it when you don't have/want a proprietary protocol.
It should be possible to distribute the calls evenly by using mod_limit. You can even take the transcoding into account. If you know your media servers will only use G711 to the outside, you can call mod_limit once if the inbound call is G711 also, but you may call mod_limit twice or thrice or more (to be calculated) if the inbound call is G729. This way, your mod_limit figures per media server will reflect the actual load on the server, not only the number of current calls.
David Ponzone Direction Technique email: david.ponzone@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 27/05/2010 à 08:15, Vitalii Colosov a écrit :
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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:+19193869900
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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
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@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@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@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@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@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@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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yup but central billing on RS? On May 30, 2010 9:05 PM, "David Ponzone" <david.ponzone@gmail.com> wrote: 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@ipeva.fr tel: 01 74 03 18 97 gsm: 06 ... 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...
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I dont think billing is an issue. You can do it on RS or on MS. You can actually collect on both to check consistency. David Ponzone Direction Technique email: david.ponzone@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 31/05/2010 à 10:10, Saeed Ahmed a écrit :
Yup but central billing on RS?
On May 30, 2010 9:05 PM, "David Ponzone" <david.ponzone@gmail.com> wrote:
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@ipeva.fr tel: 01 74 03 18 97 gsm: 06 ...
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...
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Hi David Have you (or someone here) worked with Kamailio? If it can be used to act as stateful proxy, it could work this way: Kamailio (10.10.1.1) takes the packet, determines if it is part of a certain call (maybe look at Call ID, etc.) -- or if it's a new call to pick one server -- and sends the packet to FS1 (10.10.1.2); FS1 responds with SDP containing its own IP for media; Kamilio modifies the headers (especially Contact to set its own IP instead of FS IP) and sends to carrier. This way we can have multiple FS media servers running behind one signaling IP. Since all FS servers have their own external IPs reachable from the outside network, their IPs in effect appear as media IPs to carriers and they send signaling to Kamailio but media directly to the FS server actually handling the call. Yes, it's not a pure FS solution but best tool for the job, right? Of course, I am assuming (having never worked with Kamailio) that it can handle this kind of architecture. I think it should be able to handle signaling for lots and lots of simultaneous calls because it is not handling media at all, freeing up resources for signaling only. Any thoughts? On Fri, May 28, 2010 at 6:31 AM, David Ponzone <david.ponzone@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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers . The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works. David Ponzone Direction Technique email: david.ponzone@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 04/06/2010 à 05:00, Code Ghar a écrit :
Hi David
Have you (or someone here) worked with Kamailio? If it can be used to act as stateful proxy, it could work this way: Kamailio (10.10.1.1) takes the packet, determines if it is part of a certain call (maybe look at Call ID, etc.) -- or if it's a new call to pick one server -- and sends the packet to FS1 (10.10.1.2); FS1 responds with SDP containing its own IP for media; Kamilio modifies the headers (especially Contact to set its own IP instead of FS IP) and sends to carrier.
This way we can have multiple FS media servers running behind one signaling IP. Since all FS servers have their own external IPs reachable from the outside network, their IPs in effect appear as media IPs to carriers and they send signaling to Kamailio but media directly to the FS server actually handling the call.
Yes, it's not a pure FS solution but best tool for the job, right? Of course, I am assuming (having never worked with Kamailio) that it can handle this kind of architecture. I think it should be able to handle signaling for lots and lots of simultaneous calls because it is not handling media at all, freeing up resources for signaling only.
Any thoughts?
On Fri, May 28, 2010 at 6:31 AM, David Ponzone <david.ponzone@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@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@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.htm...
I think it will fit your needs.
Regards, Vitalie
2010/5/27 Code Ghar <codeghar@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Why would it be an advantage to have your media proxies use another protocol? Mike On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
Mike, You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP. So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also. So it would like this: ------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP- External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP- External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------ Thanks to bypass-media, the RTP streams would go from customer to FS- RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders. Is there something wrong in this ? Code, does it help ? David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
David, I hope you don't mind me interjecting here. But what is the advantage of your setup over the traditional SIP Proxy - FS - SIP Proxy setup? Isn't introducing a re-invite here, to shift the media from FS-SIP-Internal-1 to FS-RTP-3 introducing a further complication and potential point of failure? Pj On Mon, Jun 7, 2010 at 7:29 AM, David Ponzone <david.ponzone@gmail.com>wrote:
Mike,
You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP.
So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also.
So it would like this:
------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP-External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP-External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------
Thanks to bypass-media, the RTP streams would go from customer to FS-RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders.
Is there something wrong in this ?
Code, does it help ?
David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
_______________________________________________
FreeSWITCH-users mailing list FreeSWITCH-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Phillip, please do :) Well, I could be wrong, but this setup should not require any re-invite. I never really used bypass-media on FS, but from what I understood, it will jut advertise the customer IP to FS-RTP-3 and FS-RTP-3's IP to the customer. Anyway, the idea of the design was an attempt to answer to Code's question at the beginning of the thread. who wanted to build a such architecture with FS only. David Ponzone Direction Technique email: david.ponzone@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 07/06/2010 à 19:02, Phillip Jones a écrit :
David,
I hope you don't mind me interjecting here. But what is the advantage of your setup over the traditional SIP Proxy - FS - SIP Proxy setup? Isn't introducing a re-invite here, to shift the media from FS-SIP-Internal-1 to FS-RTP-3 introducing a further complication and potential point of failure?
Pj
On Mon, Jun 7, 2010 at 7:29 AM, David Ponzone <david.ponzone@gmail.com> wrote: Mike,
You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP.
So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also.
So it would like this:
------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP- External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP- External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------
Thanks to bypass-media, the RTP streams would go from customer to FS- RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders.
Is there something wrong in this ?
Code, does it help ?
David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
FreeSWITCH-users mailing list FreeSWITCH-users@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I haven't used bypass-media extensively, either. So I am also interested in knowing if it would introduce re-invite. I know several carriers, using some older SIP implementations or for other reasons, do not support re-invite. In a perfect world we would use bypass-media on the ingress and egress FS-SIP servers, without introducing re-invite, and handle media using intermediate FS-RTP servers. Aside from the media, if we use, say two FS-SIP servers, then all FS-RTP servers can do load balance when doing egress. In this way we only need two signaling IPs for all kinds of customers and carriers and don't have to differentiate between ingress-only and egress-only FS-SIP servers. Each FS-SIP is ingress and egress while all FS-RTP look only like media IPs to all customers and carriers. Of course, I would like to get consensus confirmation from experienced users that bypass-media does not introduce re-invite. We could use a SIP Proxy, as advised by PJ, but if a bunch of FS servers could do that same job that would be awesome, too. On Mon, Jun 7, 2010 at 12:34 PM, David Ponzone <david.ponzone@gmail.com>wrote:
Phillip,
please do :)
Well, I could be wrong, but this setup should not require any re-invite. I never really used bypass-media on FS, but from what I understood, it will jut advertise the customer IP to FS-RTP-3 and FS-RTP-3's IP to the customer.
Anyway, the idea of the design was an attempt to answer to Code's question at the beginning of the thread. who wanted to build a such architecture with FS only.
David Ponzone Direction Technique email: david.ponzone@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 07/06/2010 à 19:02, Phillip Jones a écrit :
David,
I hope you don't mind me interjecting here. But what is the advantage of your setup over the traditional SIP Proxy - FS - SIP Proxy setup? Isn't introducing a re-invite here, to shift the media from FS-SIP-Internal-1 to FS-RTP-3 introducing a further complication and potential point of failure?
Pj
On Mon, Jun 7, 2010 at 7:29 AM, David Ponzone <david.ponzone@gmail.com>wrote:
Mike,
You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP.
So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also.
So it would like this:
------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP-External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP-External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------
Thanks to bypass-media, the RTP streams would go from customer to FS-RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders.
Is there something wrong in this ?
Code, does it help ?
David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
_______________________________________________
FreeSWITCH-users mailing list FreeSWITCH-users@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Ok so I set up a simple test: <action application="set" data="bypass_media=true"/> <action application="bridge" data="bridge,sofia/gateway/broadvox/...."/> and yes you appear to correct David - no SIP re-invite is involved - no RTP streams hit the box at all. nice. On Mon, Jun 7, 2010 at 5:31 PM, Code Ghar <codeghar@gmail.com> wrote:
I haven't used bypass-media extensively, either. So I am also interested in knowing if it would introduce re-invite. I know several carriers, using some older SIP implementations or for other reasons, do not support re-invite. In a perfect world we would use bypass-media on the ingress and egress FS-SIP servers, without introducing re-invite, and handle media using intermediate FS-RTP servers.
Aside from the media, if we use, say two FS-SIP servers, then all FS-RTP servers can do load balance when doing egress. In this way we only need two signaling IPs for all kinds of customers and carriers and don't have to differentiate between ingress-only and egress-only FS-SIP servers. Each FS-SIP is ingress and egress while all FS-RTP look only like media IPs to all customers and carriers. Of course, I would like to get consensus confirmation from experienced users that bypass-media does not introduce re-invite.
We could use a SIP Proxy, as advised by PJ, but if a bunch of FS servers could do that same job that would be awesome, too.
On Mon, Jun 7, 2010 at 12:34 PM, David Ponzone <david.ponzone@gmail.com>wrote:
Phillip,
please do :)
Well, I could be wrong, but this setup should not require any re-invite. I never really used bypass-media on FS, but from what I understood, it will jut advertise the customer IP to FS-RTP-3 and FS-RTP-3's IP to the customer.
Anyway, the idea of the design was an attempt to answer to Code's question at the beginning of the thread. who wanted to build a such architecture with FS only.
David Ponzone Direction Technique email: david.ponzone@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 07/06/2010 à 19:02, Phillip Jones a écrit :
David,
I hope you don't mind me interjecting here. But what is the advantage of your setup over the traditional SIP Proxy - FS - SIP Proxy setup? Isn't introducing a re-invite here, to shift the media from FS-SIP-Internal-1 to FS-RTP-3 introducing a further complication and potential point of failure?
Pj
On Mon, Jun 7, 2010 at 7:29 AM, David Ponzone <david.ponzone@gmail.com>wrote:
Mike,
You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP.
So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also.
So it would like this:
------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP-External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP-External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------
Thanks to bypass-media, the RTP streams would go from customer to FS-RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders.
Is there something wrong in this ?
Code, does it help ?
David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
_______________________________________________
FreeSWITCH-users mailing list FreeSWITCH-users@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Probably you will get sip re invite only if you will use "bypass_media_* after_bridge*"* *variable*.* Vitalie 2010/6/8 Phillip Jones <pjintheusa@gmail.com>
Ok so I set up a simple test:
<action application="set" data="bypass_media=true"/> <action application="bridge" data="bridge,sofia/gateway/broadvox/...."/>
and yes you appear to correct David - no SIP re-invite is involved - no RTP streams hit the box at all.
nice.
On Mon, Jun 7, 2010 at 5:31 PM, Code Ghar <codeghar@gmail.com> wrote:
I haven't used bypass-media extensively, either. So I am also interested in knowing if it would introduce re-invite. I know several carriers, using some older SIP implementations or for other reasons, do not support re-invite. In a perfect world we would use bypass-media on the ingress and egress FS-SIP servers, without introducing re-invite, and handle media using intermediate FS-RTP servers.
Aside from the media, if we use, say two FS-SIP servers, then all FS-RTP servers can do load balance when doing egress. In this way we only need two signaling IPs for all kinds of customers and carriers and don't have to differentiate between ingress-only and egress-only FS-SIP servers. Each FS-SIP is ingress and egress while all FS-RTP look only like media IPs to all customers and carriers. Of course, I would like to get consensus confirmation from experienced users that bypass-media does not introduce re-invite.
We could use a SIP Proxy, as advised by PJ, but if a bunch of FS servers could do that same job that would be awesome, too.
On Mon, Jun 7, 2010 at 12:34 PM, David Ponzone <david.ponzone@gmail.com>wrote:
Phillip,
please do :)
Well, I could be wrong, but this setup should not require any re-invite. I never really used bypass-media on FS, but from what I understood, it will jut advertise the customer IP to FS-RTP-3 and FS-RTP-3's IP to the customer.
Anyway, the idea of the design was an attempt to answer to Code's question at the beginning of the thread. who wanted to build a such architecture with FS only.
David Ponzone Direction Technique email: david.ponzone@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 07/06/2010 à 19:02, Phillip Jones a écrit :
David,
I hope you don't mind me interjecting here. But what is the advantage of your setup over the traditional SIP Proxy - FS - SIP Proxy setup? Isn't introducing a re-invite here, to shift the media from FS-SIP-Internal-1 to FS-RTP-3 introducing a further complication and potential point of failure?
Pj
On Mon, Jun 7, 2010 at 7:29 AM, David Ponzone <david.ponzone@gmail.com>wrote:
Mike,
You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP.
So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also.
So it would like this:
------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP-External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP-External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------
Thanks to bypass-media, the RTP streams would go from customer to FS-RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders.
Is there something wrong in this ?
Code, does it help ?
David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
_______________________________________________
FreeSWITCH-users mailing list FreeSWITCH-users@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Yes - you are correct - I ran a test on using bypass_media_*after_bridge*and that did issue a sip-reinvite to reroute the RTP from the FS box. On Tue, Jun 8, 2010 at 9:49 AM, Vitalii Colosov <vetali100@gmail.com> wrote:
Probably you will get sip re invite only if you will use "bypass_media_* after_bridge*"* *variable*.*
Vitalie
2010/6/8 Phillip Jones <pjintheusa@gmail.com>
Ok so I set up a simple test:
<action application="set" data="bypass_media=true"/> <action application="bridge" data="bridge,sofia/gateway/broadvox/...."/>
and yes you appear to correct David - no SIP re-invite is involved - no RTP streams hit the box at all.
nice.
On Mon, Jun 7, 2010 at 5:31 PM, Code Ghar <codeghar@gmail.com> wrote:
I haven't used bypass-media extensively, either. So I am also interested in knowing if it would introduce re-invite. I know several carriers, using some older SIP implementations or for other reasons, do not support re-invite. In a perfect world we would use bypass-media on the ingress and egress FS-SIP servers, without introducing re-invite, and handle media using intermediate FS-RTP servers.
Aside from the media, if we use, say two FS-SIP servers, then all FS-RTP servers can do load balance when doing egress. In this way we only need two signaling IPs for all kinds of customers and carriers and don't have to differentiate between ingress-only and egress-only FS-SIP servers. Each FS-SIP is ingress and egress while all FS-RTP look only like media IPs to all customers and carriers. Of course, I would like to get consensus confirmation from experienced users that bypass-media does not introduce re-invite.
We could use a SIP Proxy, as advised by PJ, but if a bunch of FS servers could do that same job that would be awesome, too.
On Mon, Jun 7, 2010 at 12:34 PM, David Ponzone <david.ponzone@gmail.com>wrote:
Phillip,
please do :)
Well, I could be wrong, but this setup should not require any re-invite. I never really used bypass-media on FS, but from what I understood, it will jut advertise the customer IP to FS-RTP-3 and FS-RTP-3's IP to the customer.
Anyway, the idea of the design was an attempt to answer to Code's question at the beginning of the thread. who wanted to build a such architecture with FS only.
David Ponzone Direction Technique email: david.ponzone@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 07/06/2010 à 19:02, Phillip Jones a écrit :
David,
I hope you don't mind me interjecting here. But what is the advantage of your setup over the traditional SIP Proxy - FS - SIP Proxy setup? Isn't introducing a re-invite here, to shift the media from FS-SIP-Internal-1 to FS-RTP-3 introducing a further complication and potential point of failure?
Pj
On Mon, Jun 7, 2010 at 7:29 AM, David Ponzone <david.ponzone@gmail.com>wrote:
Mike,
You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP.
So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also.
So it would like this:
------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP-External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP-External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------
Thanks to bypass-media, the RTP streams would go from customer to FS-RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders.
Is there something wrong in this ?
Code, does it help ?
David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
_______________________________________________
FreeSWITCH-users mailing list FreeSWITCH-users@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@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@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@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@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I haven't had a chance to actually test this config in lab but I will in the coming days. One issue I see is when we use registered endpoints, such as ATAs, behind NAT: bypass_media fails in this case because FS uses the private network IP instead of the public network IP in SDP. In case of a large number of such registered endpoints, we may have to make them talk with an FS-RTP server directly because they don't use bypass_media while FS-SIP does. Can we use bypass_media_after_reinvite for them or would it have the same behavior of using private IP? Or we could use proxy_media; which is not want we really want to do but could work in a pinch. Or is there a better way to combine bypass_media with NAT'ed endpoints? On Mon, Jun 7, 2010 at 6:29 AM, David Ponzone <david.ponzone@gmail.com>wrote:
Mike,
You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP.
So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also.
So it would like this:
------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP-External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP-External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------
Thanks to bypass-media, the RTP streams would go from customer to FS-RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders.
Is there something wrong in this ?
Code, does it help ?
David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
_______________________________________________
FreeSWITCH-users mailing list FreeSWITCH-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
I don't see the issue. They will send their RTP to FS-RTP-x, and FS-RTP-x will autoadjust to this stream in order to learn the real IP:port of the endpoint. David Ponzone Direction Technique email: david.ponzone@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 18/06/2010 à 00:46, Code Ghar a écrit :
I haven't had a chance to actually test this config in lab but I will in the coming days. One issue I see is when we use registered endpoints, such as ATAs, behind NAT: bypass_media fails in this case because FS uses the private network IP instead of the public network IP in SDP. In case of a large number of such registered endpoints, we may have to make them talk with an FS-RTP server directly because they don't use bypass_media while FS-SIP does. Can we use bypass_media_after_reinvite for them or would it have the same behavior of using private IP? Or we could use proxy_media; which is not want we really want to do but could work in a pinch. Or is there a better way to combine bypass_media with NAT'ed endpoints?
On Mon, Jun 7, 2010 at 6:29 AM, David Ponzone <david.ponzone@gmail.com> wrote: Mike,
You're right, it can be achieved with SIP now that I think a bit more about it. The idea was to allow adding multiple media gateways when required, so the media gateways should not be facing the carriers as some of them do SIP-filtering, but should only be advertised in the SDP.
So SIP-only boxes (doing bypass-media) should face the carriers to handle the trunking. In the middle, we would then have the media gateways, doing SIP and mostly RTP. But I guess we dont want customers to register and to send calls to a media gateway, so we need another set of SIP boxes on the other side, doing bypass-media also.
So it would like this:
------sip-----FS-RTP-1-----sip------ FS-SIP-Internal-1 ------sip-----FS-RTP-2-----sip------FS-SIP- External-1----sip-----Carriers ------sip-----FS-RTP-3-----sip------ FS-SIP-Internal-2 -------sip----FS-RTP-4-----sip------FS-SIP- External-2-----sip----Carriers -------sip----FS-RTP-5-----sip------
Thanks to bypass-media, the RTP streams would go from customer to FS- RTP-x to Carriers, and reverse. And I don't see any reason why the same set of FS-SIP boxes could not be used for both internal and external borders.
Is there something wrong in this ?
Code, does it help ?
David Ponzone Direction Technique email: david.ponzone@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 05/06/2010 à 19:54, Michael Jerris a écrit :
Why would it be an advantage to have your media proxies use another protocol?
Mike
On Jun 4, 2010, at 1:59 AM, David Ponzone wrote:
It doesn't solve the issue that all the media servers will do signaling too, and will talk SIP with the carriers. So the carriers will need to allow all the media servers .
The only clean solution to avoid that, I think, is to have signaling boxes allocating resources from media servers with another protocol than SIP. RTPproxy does that I think, but I am not sure how it works.
David Ponzone
FreeSWITCH-users mailing list FreeSWITCH-users@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@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (7)
-
Anthony Minessale
-
Code Ghar
-
David Ponzone
-
Michael Jerris
-
Phillip Jones
-
Saeed Ahmed
-
Vitalii Colosov