[asterisk-users] Internal calls without voice transport

[martin f krafft]

By chance, I managed to fig into this a bit and found the exact
moment when audio stops. It is exactly the moment when the
counterparty picks up and RTP debug output says:

  Got  RTP packet from    46.244.255.146:8058 (type 00, seq 000680, ts 340914880, len 000160)
  Sent RTP packet to      46.244.255.146:8058 (type 00, seq 026000, ts 3578986600, len 000160)
      -- SIP/lehel-sipgate-00003573 answered SIP/lehel-martin-00003572
      -- Remotely bridging SIP/lehel-martin-00003572 and SIP/lehel-sipgate-00003573
  Sent RTP P2P packet to 46.244.255.146:8058 (type 08, len 000160)
  Sent RTP P2P packet to 46.244.255.146:8058 (type 08, len 000160)

so RTP switches to RTP P2P and no more packets are received from the
phone.

I did have a sniffer running on 46.244.255.146, and Wireshark really
rocks, so now I know that the gateway firewall is at fault, and
indeed, for some reason, nf_conntrack_sip and nf_nat_sip were not
loaded. Now I am wondering how it worked in the first place, but
that's that. Maybe this will fix things.

Anyway, I don't quite yet understand what RTP P2P packets are or why
they are sometimes used and not at other times. I assume they are
packets intended to be exchanged directly between the two clients,
but since I have MixMonitor() on Asterisk, this shouldn't actually
be possible as Asterisk should always force itself into the middle.

Thoughts?

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
dies ist eine manuell generierte email. sie beinhaltet
tippfehler und ist auch ohne großbuchstaben gültig.
 
spamtraps: madduck.bogus at madduck.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: digital_signature_gpg.asc
Type: application/pgp-signature
Size: 1107 bytes
Desc: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140728/ec31f099/attachment.pgp>