[Freeswitch-users] Can FS avoid sending re-INVITE to client? Or bridge on its behalf?

[Michael Jerris]

> On May 29, 2018, at 3:12 PM, M Yudkowsky <speech at pobox.com> wrote:
> 
> Comrades!
> 
> I'd like to find out of if FS, which is making calls on behalf of a client, can intercept timer-based re-INVITEs and respond to them without sending the INVITE to the client first. Alternatively, can FS be made smart enough to bridge "in the cloud" on behalf a  client, even if the client uses internal RTP port numbers?

Freeswitch deals with each leg individually unless you tell it otherwise.  session timer re-invite on one side would not normally trigger a re-invite on the other, at least with default settings.  In bypass media mode I believe it always still does.

> 
> Details:
> 
> I've got an internal server (IS) that uses FS as a firewall. The IS asks for leg A, then leg B, and then bridges leg A and leg B "in the cloud." FS (working in media bypass mode) handles this without any problems.

why are you starting each leg then bridging, starting them manually instead of just using the bridge app to start the b leg is probably the root of your issue.  when you start individually there is no codec coordination for example.

> 
> For many non-NANP and some NANP calls, some SIP providers insist on a re-INVITE every 5 to 15 minutes.
> 
> Unfortunately, the IS has a bug: if you send it a re-INVITE -- which is what FS does at this point -- the IS will respond correctly and continue the call in the cloud. But at the same time, the IS will open an internal RTP port (which is not used for anything) and then fail 60s later when no RTP reaches that port.

Need more info on what config you have,  by default it wont be sending this re-invite, in bypass media it does as we don’t parse the sdp at all in that case, just pass to the other side.  To determine this is just a session timer re-invite we would have to parse and see its a dup sdp to skip it.

> 
> At this point, the IS sends a BYE for one of the legs, requests the other leg back from the cloud, and continues to handle the remaining leg. Note that the IS in the course of normal processing does break the cloud conference, talk to each individual leg,  bridges them together again or each with some other new leg... it's quite a dance of INVITEs and re-INVITEs that the IS sends. But inbound re-INVITEs related to timers is the problem at the moment.
> 
> 
> Two possible solutions: 
> 
> Solution A. Is there a way for FS to be made smart enough and aggressive enough to act on a routine, timer-related re-INVITE? If so, this would bypass the bug in our IS.
> 
> Solution B. When FS is set to bypass RTP media, the bridge happens up in the cloud. In normal operating mode, without bypass or proxy of RTP set, this is what happens: When the IS attempts to bridge the calls it sends the bridging re-INVITEs to FS, and those re-INVITEs are for _internal_ ports that FS offered to the IS. FS bridges these internal ports but (and perhaps I'm reading Wireshark wrong) does not attempt to bridge the external ports and take the media into the cloud. The bridge is done on FS itself. A possible solution, then, would be to configure FS to determine that the media can be bridged in the cloud and have it do so.
> 

Why are we doing internal ports here?

> 
> -- 
>  Moshe Yudkowsky
>  Disaggregate Corporation
>  2952 W Fargo
>  Chicago, IL 60645 USA
> 
>  +1 773 764 8727
>   speech at pobox.com
> 
>   http://www.Disaggregate.com
>   http://www.PebbleAndAvalanche.com
> 
> 
> 
> 
> 
> 
> 
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
> 
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://confluence.freeswitch.org
> http://www.cluecon.com
> 
> 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