5 Dec
2008
5 Dec
'08
12:03 a.m.
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(a)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(a)72.66.211.59
72.66.211.59 19994 as3257bf0a;1"
:new session 565aabb151708c9c46c744d2400a454b(a)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(a)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(a)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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers