[Freeswitch-users] FS as Media Gateway Only

Mon Jun 7 14:31:34 PDT 2010

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 at 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 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 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 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
>>
>>
> _______________________________________________
> 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/20100607/de407b42/attachment.html 