[Freeswitch-users] FS as Media Gateway Only
Phillip Jones
pjintheusa at gmail.com
Tue Jun 8 08:16:32 PDT 2010
Yes - you are correct - I ran a test on using
bypass_media_*after_bridge*and that did issue a sip-reinvite to
reroute the RTP from the FS box.
On Tue, Jun 8, 2010 at 9:49 AM, Vitalii Colosov <vetali100 at gmail.com> wrote:
> 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
>>
>>
>
> _______________________________________________
> 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/71e1fe6a/attachment-0001.html
More information about the FreeSWITCH-users
mailing list