[Freeswitch-users] FS as Media Gateway Only

Tue Jun 8 06:37:54 PDT 2010

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 at 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 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
>>
>>
>
> _______________________________________________
> 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/20100608/b6944500/attachment-0001.html 