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