[Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?

[Greger Viken Teigre]

Look for direction=active or passive in SDP. You signal to the UA whether  
they should expect an active or passive UA.
See http://www.iptel.org/ser/doc/modules/nathelper

As I said, waiting for media makes sense if you believe that the user  
agent is behind a NAT and the NAT may change the original port. The only  
way to get through is to wait until you get a packed and send back on the  
src port, hoping the NAT is symmetric.
g-)

On Thu, 04 Dec 2008 21:12:28 +0100, Frank Durda IV
<frank.durda at hypercube-llc.com> wrote:

> Here is the output from rtpproxy interspersed with comments
> about what was going on externally, as well as lsof output:
>
>
> System quiet, no calls in progress.
> Placing call:
>
> :received command "UE 565aabb151708c9c46c744d2400a454b at 72.66.211.59  
> 72.66.211.59 19994 as3257bf0a;1"
> :new session 565aabb151708c9c46c744d2400a454b at 72.66.211.59, tag  
> as3257bf0a;1 requested, type strong
> :new session on a port 35008 created, tag as3257bf0a;1
> :sending reply "35008 10.31.168.18
> :"
> :received command "L 565aabb151708c9c46c744d2400a454b at 72.66.211.59  
> 10.131.0.2 16004 as3257bf0a;1 000a0283+1+4e00002+48ad7f8b
> "
> :lookup on ports 35008/35008, session timer restarted
> :sending reply "35008 10.81.168.2
> :"
> :callee's address filled in: 10.31.168.2:16004 (RTP)
> :guessing RTCP port for callee to be 16005
> :
> :(lsof says)
> :rtpproxy 68032 root    5u  IPv4 0xffffff0026117850      0t0      UDP  
> 10.31.168.18:35008
> :rtpproxy 68032 root    6u  IPv4 0xffffff00113d6980      0t0      UDP  
> 10.31.168.18:35009
> :rtpproxy 68032 root    7u  IPv4 0xffffff001fed65f0      0t0      UDP  
> 10.81.168.2:35008
> :rtpproxy 68032 root    8u  IPv4 0xffffff0015324720      0t0      UDP  
> 10.81.168.2:35009
>
> 10.81.168.2 faces the calling party (router, then asterisk then cisco  
> phone)
> 10.31.168.18 faces the PSTN gateway switch (called party is there)
>
> Called number ringing.
> Despite letting called number ring several times, calling
> party hears no ring back audio or any other audio.
> The Ring-back audio is being sent to rtpptroxy (tcpdump shows this),
> but is being thrown away, despite "filled in" thing above.
> Stats below from rtpproxy also show large discard.
>
>
> Call is now answered, and neither party can hear audio from one another.
> No new messages are emitted from rtpproxy.
> Audio is being sent to rtpptroxy by called system, but is being
> thrown away.  (Calling system audio is blocked by the router as
> part of the test.)
>
> This state demonstrates the "neither party will blink" deadly
> embrace scenario, if the calling system refused to send audio
> until it received audio from the called direction, which would
> be a rtpproxy daemon, or worse, two rtpproxy daemons facing
> each other.
>
>
> Now, allowing inbound RTP audio is allowed from calling party
> by removing the router restriction on incoming UDP packets
> to ports other than 5060:
>
> :caller's address filled in: 72.66.211.59:19994 (RTP)
> :guessing RTCP port for caller to be 19995
> :
> :(lsof says)
> :rtpproxy 68032 root    5u  IPv4 0xffffff0026117850      0t0      UDP  
> 10.31.168.18:35008
> :rtpproxy 68032 root    6u  IPv4 0xffffff00113d6980      0t0      UDP  
> 10.31.168.18:35009
> :rtpproxy 68032 root    7u  IPv4 0xffffff001fed65f0      0t0      UDP  
> 10.81.168.2:35008
> :rtpproxy 68032 root    8u  IPv4 0xffffff0015324720      0t0      UDP  
> 10.81.168.2:35009
>
>
> Both parties instantly can now hear each others' audio.
> This demsonatres that BOTH sides must be filled in before
> the audio passes for either, just as documented (but
> terrible behavior).
>
> After a minute or so, Calling party goes on hook:
>
> :received command "D 565aabb151708c9c46c744d2400a454b at 72.66.211.59  
> as3257bf0a 000
> :a0283+1+4e00002+48ad7f8b"
> :forcefully deleting session 1 on ports 35008/35008
> :RTP stats: 2753 in from callee, 1459 in from caller, 2920 relayed, 1292  
> dropped
> :RTCP stats: 10 in from callee, 6 in from caller, 12 relayed, 4 dropped
> :session on ports 35008/35008 is cleaned up
> :sending reply "0
> :"
> :
> :lsof shows no IPV4 ports open.
>
>
> Called phone goes on hook.
> End of session.
>
>
> Note that even rtproxy stats show that it was throwing away most of the
> audio coming from called party (this is G.711 so packet counts after
> going off-hook should be about the same), which shouldn't be the
> case if it allows the audio to pass as soon as it gets the details
> from the called party, details that arrive before or just as the
> audio starts to arrive (when 183 is sent).
>
> I think I have demonstrated the problem now several convincing
> ways now.  What is needed is a fix.
> Or is it just as simple as ripping out the
>         if (sp->complete != 0) {
>         }
> in main.c?   I feel a tad uncomfortable about the side-effects
> of doing that, but it looks somewhat underprotected anyway.
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Serusers mailing list
> Serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers