<div dir="ltr"><div dir="auto"><div dir="ltr">Hi Babak, sorry for the late reply. I've been quite busy here lately.<div><br></div><div>Your setup seems very complicated, I am not sure if that's for a reason or something that "just happened". One immediate problem is that the call is proxied twice - even before FS is switched in, the RTP already takes 4 hops:</div><div><br></div><div>RTP in, ssrc=0x3a8d7fbe: 205.1:4008 -> 205.34:20042/20012 -> 205.34:20068/20020 -> 205.1:4006<br>RTP out,
ssrc=0x339a275d: 205.1:4006 -> 205.34:20020/20068 -> 205.34:20012/20042 -> 205.1:4008<br></div><div><br></div><div>Two hops in the middle is basically RTPPproxy sending packets to itself between call legs. This of course increases delay and jitter, as well as doubles the work for the RTPProxy. It is a good practice to only pin media once in general, either when the inbound leg comes in or when outbound leg goes out</div><div><br></div><div>Now, a little bit later FS comes in and tries to update both legs to make the session like the following. Square brackets indicate the part where packets don't reach:</div><div><br></div><div>RTP in, ssrc=0xf7229438: 205.129:18804 -> 205.134:20068 <font color="#000000">[</font><font color="#ff0000">/20020 -> 205.1:4006</font>]<br>RTP out, ssrc=0xf71e7468: 205.129:17100 -> 205.134:20012 [<font color="#ff0000">/20042 -> 205.1:4008</font>]<br></div><div></div><div><br></div><div>The reason this does not really work I think is that the RTPProxy historically and by design treats any IP/port in the re-INVITE with utter suspicion, more like a hint than actual direction by default. This is because it's designed to provide NAT traversal in the majority of cases. Including the weird case of either side to "float" to the new IP:port without any notification from the signalling end (i.e. roaming between hot spots).</div><div dir="auto"><br></div><div dir="auto">So it normally expects the original sender to stop sending packets before it can fully switch over to the new IP/port from the re-INVITE. In your case, however, since original endpoints are shielded from the port change in re-INVITE by the virtue of having rtpproxy essentially in the middle of the call twice on both sides (i.e. you are trying to go from UA1<->RTPP(1)<->RTPP(2)<->UA2 to UA1<->RTPP(1)<->FS<->RTPP(2)<->UA2 and then back when the playback is done) , both sessions in the RTPProxy keep receiving packets from their originally latched sources, i.e. RTPP(1) continues receiving packets from RTPP(2) and new stream comes from FS and RTPP(2) keeps receiving packets from RTPP(1) and FS starts sending, that re-latch never happens on neither end. On top of that, the stream generated by the FS has (obviously) different SSRC, so again it makes RTPProxy a bit suspicious if it's some kind of foul play (google "RTP Bleed" attack) and very reluctant to switch over.</div><div dir="auto"><br></div><div dir="auto">I cannot tell for sure since I am not familiar with its logic and defaults, but I suspect the rtpengine has none of those features, which may explain the difference... </div><div dir="auto"><br></div><div dir="auto">In any case the situation ends up in a stalemate: both RTPP sessions keep happily receiving/sending packets from each other, totally ignoring that additional streams from the FS.</div><div><br></div><div>Now, as I said there at least one solution to your particular problem, in fact more like at least 4:</div><div dir="auto"><br></div><div dir="auto">1. Since having two sessions on both ends is wasteful and inefficient, consider straightening that out. So instead make your RTP path look like the following:</div><div><br></div><div>UA1<->OPENSIPS/RTPP<->OPENSIPS<->UA2</div><div><br></div><div>Then when FS comes in and triggers re-invite on both legs, the UA1 would be shielded from that port change, while UA2 won't (since there is no RTPProxy on the outbound leg). As a result UA2 would start sending RTP directly to FS (as opposed to the RTPProxy), the RTPProxy would stop receiving that traffic from UA2 on its outbound "leg" and latch FS instead, resulting in a proper RTP path being:</div><div><br></div><div>UA1<->RTPP<->FS<->UA2</div><div dir="auto"><br></div><div dir="auto">This may or not may be solution to your problem. If you still want for whatever reason shield UA2 from getting RTP traffic directly from the FS, then my next pick is:</div><div dir="auto"><br></div><div dir="auto">2) Only create RTPP(2) session when FS wants to talk and abandon when it stops. This can be accomplished by enabling OpenSIPS on inbound call leg to append a:nortpproxy=yes attribute (default behavior) and OpenSIPS on the outbound leg obey it. Then original session would look like expected, i.e.:</div><div dir="auto"><br></div><div dir="auto">UA1<->RTPP(1)<->UA2</div><div dir="auto"><br></div><div dir="auto">Then when FS intervenes, neither of re-INVITEs has that attribute, so the new RTPP session on outbound leg is allocated and the chain becomes:</div><div dir="auto"><br></div><div dir="auto">UA1<->RTPP(1)<->FS<->RTPP(2)<->UA2</div><div dir="auto"><br></div><div dir="auto">RTPP(1) stops receiving RTP from the UA2 and happily re-latches to FS instead. :)</div><div dir="auto"><br></div><div dir="auto">Then again after FS drops out that should reduce the RTP flow back to the following and RTPP(2) session eventually timeouts:</div><div><div dir="auto"><br></div><div dir="auto">UA1<->RTPP(1)<->UA2</div></div><div><br></div><div dir="auto">3) Disable any NAT compensation in the RTPProxy in general. Bit of a hevy-weight, but if you expect both UA1 and UA2 to provide trustworthy IP:port in the SDP i.e. if you are only concerned with the topology hiding and don't have NAT in or out it might be the easiest way to go. This should make RTPProxy obey any IP:port combinations it gets from OpenSIPS verbatim. There was functionality for that in RTPProxy, however turns out it was not exposed, so I've just added a new option for that --force_asymmetric (<a href="https://github.com/sippy/rtpproxy/compare/f18630dfa014...7be7d5598a4e">https://github.com/sippy/rtpproxy/compare/f18630dfa014...7be7d5598a4e</a>)</div><div dir="auto"><br></div><div dir="auto">4) Disable NAT compensation for the RTP "leg" that goes to/fro FS. This one might be a bit trickier to implement - you'd have to have a logic in both request route and response route to add "A" flag into (re-)INVITE that goes from FS and 200/183 that it generates.</div><div dir="auto"><br></div><div dir="auto">Hope it helps. 😀</div><div dir="auto"><br></div><div>-Max</div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 5:22 AM Babak Yakhchali <<a href="mailto:babak.yakhchali@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">babak.yakhchali@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The same configuration worked with rtp-engine</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 12:58 PM Babak Yakhchali <<a href="mailto:babak.yakhchali@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">babak.yakhchali@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I tried the latest rtpproxy from github and prompt is played successfully. But after the prompt is played, freeswitch sends two re-invites to clients to remove itself from the rtp path. In these re-invties freeswitch places initial rtpproxy generated ports for clients. Everything is logically ok but when I capture rtp traffic I can see that rtpproxy is still sending rtp packets to freeswitch which is wrong. It should be noted that after the last re-invites freeswitch stops sending rtp to rtpproxy so there will be no new re-latching.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 21, 2020 at 5:09 PM Babak Yakhchali <<a href="mailto:babak.yakhchali@gmail.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">babak.yakhchali@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><span style="font-size:small">Hi</span><div><div style="font-size:small">I'm trying to handle a mid call playback using opensips with rtpproxy on the same box and a freeswith server as media server like this:</div><div style="font-size:small">client1 and client2 <=> opensips (rtpproxy on same box) <=> freeswitch</div><div style="font-size:small"><img src="https://mail.google.com/mail/u/1?ui=2&ik=2aa05ffe6f&attid=0.0.1&permmsgid=msg-a:r-5724847549617293799&th=1734c38c9532d96b&view=fimg&sz=s0-l75-ft&attbid=ANGjdJ_Z8yJp3WZrUo1JwcHUpDIoP7bBLzx4aGj_5OyB1LK-6OX75vMu5jY4RiGWqyQmcaJVG-O1RWnGd233MY7pEK2WD5_zvRxEFGFOJF24mqrwDK6VovTnvg81Kv4&disp=emb&realattid=ii_kclm27kp1" alt="arch.jpg" width="452" height="233" style="outline: 0px;"><br></div><div style="font-size:small">At start freeswitch is involved in signaling but not in the rtp session and rtp goes through rtpproxy to clients. After 3 seconds freeswitch sends re-invites to come to the rtp session and play the sound file to both clients and after playback sends re-invites to leave the rtp path.</div><div style="font-size:small">All sip signalling is done correctly and the sound file is played successfully(as I can see in freeswitch console and analyzing captures), but nothing is heard on clients.</div><div style="font-size:small"><br></div><div style="font-size:small">Can rtpproxy handle such a scenario?</div><div style="font-size:small"><br></div><div style="font-size:small">opensips version is 2.4 git branch</div><div style="font-size:small">rtpproxy version is 2.2.alpha.61e74c0</div><div style="font-size:small"><br></div><div style="font-size:small">I've attached my opensips config with rtpproxy log and packet capture</div><div style="font-size:small"><br></div><div style="font-size:small">thanks</div></div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "rtpproxy" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:rtpproxy+unsubscribe@googlegroups.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">rtpproxy+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/rtpproxy/23208bff-2eb4-424a-95b3-ef800a2ea41do%40googlegroups.com?utm_medium=email&utm_source=footer" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://groups.google.com/d/msgid/rtpproxy/23208bff-2eb4-424a-95b3-ef800a2ea41do%40googlegroups.com</a>.<br>
</blockquote></div>
</blockquote></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "rtpproxy" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:rtpproxy+unsubscribe@googlegroups.com" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">rtpproxy+unsubscribe@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/rtpproxy/CAD3oNZwHQWu9WA2xKfLys9A89KvZ5mq36v4OD14zBP0rK%2BHR6Q%40mail.gmail.com?utm_medium=email&utm_source=footer" rel="noreferrer noreferrer noreferrer noreferrer" target="_blank">https://groups.google.com/d/msgid/rtpproxy/CAD3oNZwHQWu9WA2xKfLys9A89KvZ5mq36v4OD14zBP0rK%2BHR6Q%40mail.gmail.com</a>.<br>
</blockquote></div><br clear="all"><div><br></div>