Can FS avoid sending re-INVITE to client? Or bridge on its behalf?
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? 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 -- 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. 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. -- Moshe Yudkowsky Disaggregate Corporation 2952 W Fargo Chicago, IL 60645 USA +1 773 764 8727 speech@pobox.com http://www.Disaggregate.com http://www.PebbleAndAvalanche.com
On May 29, 2018, at 3:12 PM, M Yudkowsky <speech@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@pobox.com
http://www.Disaggregate.com http://www.PebbleAndAvalanche.com
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Michael, thanks for your reply.
On May 29, 2018, at 14:37 , Michael Jerris <mike@jerris.com> wrote:
On May 29, 2018, at 3:12 PM, M Yudkowsky <speech@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.
In our system, our separation of concerns is: Internal Server (IS): intelligence to handle inbound calls, web-initiated calls, and subsequent outbound calls. In present production, IS connects directly to SIP providers. In this test environment, it connects to FS instead. FS: a firewall between IS and the world. Certainly it will cut SIP attacks to zero, but I'd also like to use it to fix the re-INVITE problem. A typical scenario: * Someone clicks on a web page. IS makes an outbound call. In the scenario tested here, that outbound call is routed via FS. FS calls, connects IS, and the user interacts with IS. * The user wants to conference someone in. IS makes an outbound call to FS, and FS to the 2nd user. * The 2nd user assents to speak to the first one. IS sends re-INIVTEs to FS to join the two users in the cloud, and FS sends that request onwards * At various points in the call, the users may reconnect, as individuals, to IS. This requires re-INIVITEs, etc.
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.
Codec coordination is not an issue in this environment. The constraints I'm under -- a complex IS that is already fully developed and mature; the need to handle legs separately and interact with them; the need to mix them and unmix them -- is what drives me to the separation of concerns. If I were developing this system from scratch I'd certainly consider something completely different.
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.
Let me see if I understand that: 1) In bypass media mode, the re-INIVTE is automatically handed onwards. 2) In proxy media mode, or in the default mode (media flows through the FS platform), the re-INVITE would be handled at the FS level. I was unable to get proxy to work correctly for me, but now that bypass is working, I can go back and re-try proxy and see if RTP ends up in the cloud or not.
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?
There are two difficulties: * The bug, where after the re-INIVITE the IS sets up some port -- you're right, it's on a port visible to the external world -- and listens to it, *despite the fact that it sent out an invite to bridge the RTP in the cloud*. * The other issue I ran into was attempting to use default mode. In default mode, the RTP is flows through FS. As a result, during the bridge scenario: 1) IS sends an INVITE to FS asking that port IS-1 be connected to port IS-2, to bridge the audio in the cloud as determined by IS -- FS is the cloud to IS. 2) FS does not turn around and send INVITEs out for IS-1 and IS-2, and now that I think on it, rightly so: FS can't prove those ports are publicly visible. Instead, FS just bridges media between IS-1 and IS-2. The users connected to those ports are therefore bridged via FS. My next test, therefore, is to see if I can get proxy mode to work and then try bridging. My experience has been that proxy mode failed. -- Moshe Yudkowsky Disaggregate Corporation 2952 W Fargo Chicago, IL 60645 USA +1 773 764 8727 speech@pobox.com http://www.Disaggregate.com http://www.PebbleAndAvalanche.com
Are you using bypass media? try without.
On May 30, 2018, at 1:59 PM, M Yudkowsky <speech@pobox.com> wrote:
Michael, thanks for your reply.
On May 29, 2018, at 14:37 , Michael Jerris <mike@jerris.com <mailto:mike@jerris.com>> wrote:
On May 29, 2018, at 3:12 PM, M Yudkowsky <speech@pobox.com <mailto:speech@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.
In our system, our separation of concerns is:
Internal Server (IS): intelligence to handle inbound calls, web-initiated calls, and subsequent outbound calls. In present production, IS connects directly to SIP providers. In this test environment, it connects to FS instead.
FS: a firewall between IS and the world. Certainly it will cut SIP attacks to zero, but I'd also like to use it to fix the re-INVITE problem.
A typical scenario:
* Someone clicks on a web page. IS makes an outbound call. In the scenario tested here, that outbound call is routed via FS. FS calls, connects IS, and the user interacts with IS. * The user wants to conference someone in. IS makes an outbound call to FS, and FS to the 2nd user. * The 2nd user assents to speak to the first one. IS sends re-INIVTEs to FS to join the two users in the cloud, and FS sends that request onwards * At various points in the call, the users may reconnect, as individuals, to IS. This requires re-INIVITEs, etc.
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.
Codec coordination is not an issue in this environment. The constraints I'm under -- a complex IS that is already fully developed and mature; the need to handle legs separately and interact with them; the need to mix them and unmix them -- is what drives me to the separation of concerns.
If I were developing this system from scratch I'd certainly consider something completely different.
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.
Let me see if I understand that:
1) In bypass media mode, the re-INIVTE is automatically handed onwards.
2) In proxy media mode, or in the default mode (media flows through the FS platform), the re-INVITE would be handled at the FS level.
I was unable to get proxy to work correctly for me, but now that bypass is working, I can go back and re-try proxy and see if RTP ends up in the cloud or not.
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?
There are two difficulties:
* The bug, where after the re-INIVITE the IS sets up some port -- you're right, it's on a port visible to the external world -- and listens to it, *despite the fact that it sent out an invite to bridge the RTP in the cloud*.
* The other issue I ran into was attempting to use default mode. In default mode, the RTP is flows through FS. As a result, during the bridge scenario:
1) IS sends an INVITE to FS asking that port IS-1 be connected to port IS-2, to bridge the audio in the cloud as determined by IS -- FS is the cloud to IS.
2) FS does not turn around and send INVITEs out for IS-1 and IS-2, and now that I think on it, rightly so: FS can't prove those ports are publicly visible. Instead, FS just bridges media between IS-1 and IS-2. The users connected to those ports are therefore bridged via FS.
My next test, therefore, is to see if I can get proxy mode to work and then try bridging. My experience has been that proxy mode failed.
participants (2)
-
M Yudkowsky
-
Michael Jerris