[Freeswitch-users] FS as Media Gateway Only

Tue Jun 8 06:49:02 PDT 2010

Probably you will get sip re invite only if you will use "bypass_media_*
after_bridge*"* *variable*.*

Vitalie


2010/6/8 Phillip Jones <pjintheusa at 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 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
>>
>>
>
> _______________________________________________
> 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/8e76eed2/attachment.html