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

[M Yudkowsky]

Comrades!

(with some corrections, IN UPPER CASE, as some words went astray in editing.)

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?

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.

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 -- WHEN THE SIP PROVIDER SENDS A RE-INVITE TO FS, AND THEN FS SENDS IT ON TO THE IS -- 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. THIS ERROR IS NOT RELATED TO FS AT ALL AND HAPPENS EVEN WHEN THE IS INTERACTS DIRECTLY WITH THE SIP PROVIDER.

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? THIS WOULD MEAN FS WOULD AUTOMATICALLY RESPOND TO THE RE-INVITE AND NOT SEND IT ON TO THE IS. 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.




-- 
  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