[Freeswitch-users] FS as Media Gateway Only

[Code Ghar]

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 at 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 at ipeva.fr
> tel:      01 74 03 18 97
> gsm:   06 66 98 76 34
>
> Service Client IPeva
> tel:      0811 46 26 26
> www.ipeva.fr  -   www.ipeva-studio.com
>
> *Ce message et toutes les pièces jointes sont confidentiels et établis à
> l'intention exclusive de ses destinataires. Toute utilisation ou diffusion
> non autorisée est interdite. Tout message électronique est susceptible
> d'altération. **IPeva** décline toute responsabilité au titre de ce
> message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas
> destinataire de ce message, merci de le détruire immédiatement et d'avertir
> l'expéditeur.*
> *
> *
>
>
>
> Le 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
>
> _______________________________________________
> FreeSWITCH-users mailing list
> FreeSWITCH-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100617/06fc3b95/attachment.html