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@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@72.66.211.59 72.66.211.59 19994 as3257bf0a;1" :new session 565aabb151708c9c46c744d2400a454b@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@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@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers