Wierd RTP Issue

Home » Asterisk Users » Wierd RTP Issue
Asterisk Users 14 Comments

I have a peculiar RTP issue. I’m experimenting with Jitsi as a softphone on one of my desktop Windows machines. That machine can either be connected to Asterisk via an VPN connection (with a static IP address) or not (via NAT). When it’s connected via NAT, all is OK.

When it’s connected with VPN, the following occurs:

The voice path inbound to Jitsi works fine when Jitsi originates the call, no matter what it’s calling.

The voice path inbound to Jitsi works fine when it’s called from another SIP

The voice path inbound to Jitsi is silent when it’s called from something on the other side of a PRI via DAHDI.

I’ve run Wireshark on my desktop and see the RTP packets coming at the same rate and protocol (g711) in all the cases and “sip set debug peer xyz”
doesn’t shed any light on the situation (the SDP data looks similar in the working and non-worknig cases).

Does anybody have any ideas what to look at next?

14 thoughts on - Wierd RTP Issue

  • Richard Kenner wrote:

    What’s the configuration like for Jitsi in sip.conf? What version of Asterisk? What does the SIP signaling look like?


  • Just fullname and md5secret plus a “phones” section that reads:

    type=friend host=dynamic context=SIP_Phones cc_agent_policy=generic cc_monitor_policy=generic disallow=all allow=gsm allow=ulaw allow=g729


    I don’t follow. It’s just the standard INVITE/Ring/OK.

  • Richard Kenner wrote:

    What NAT settings are globally in use? Do you have directmedia turned off or on?

    This really does indeed feel like a weird NAT issue that is probably configuration related (probably both in Jitsi and Asterisk).

  • nat=yes

    I’ve tried both ways, but I normally have it off.

    Except that:

    (1) It *works* when there’s NAT and *doesn’t* work when everything has
    a static IP.

    (2) I see the RTP packets arriving: if it were NAT, I’d expect *not* to
    see them.

    (3) It depends on the direction of the call and on whether it’s SIP->SIP
    or DAHDI->SIP (and directmedia is off).

  • Richard Kenner wrote:

    Yeah this is so weird that packet captures are really needed. A working call and a non-working call, along with what IP ranges are what.

  • There are *tremendous* numbers of RTP packets, of course. Are those captures really going to be useful? That’s the problem. If they
    *are* going to be useful, then how many packets should I save? I did look at the “sip debug” output, as I said, and those look the same.

    I ran into this on a machine that I won’t be at for another two weeks, but I can see if I can reproduce it on similar machine.

  • Richard Kenner wrote:

    Not that many RTP packets are required. It’s just important to see the SIP signaling and where traffic is coming/going from with the network topology in mind. That way a clearer picture of where it’s saying media should go to, where it’s sending media from, etc can be gleamed. Once that is figured out then the problem can be isolated.

  • OK, I’ll try to reproduce on this machine and send that off. However, I did look at the SIP signaling and src/dst IP addresses and they’re all as expected between the two calls: I really fear that the difference is in the contents of the RTP stream.

  • Richard Kenner wrote:

    Few suggestions:

    1. Remove allow=gsm from your sip.conf and reload
    2. Disable ZRTP in Jitsi by going into Options -> Accounts -> Selecting account -> Edit -> Security -> Uncheck “Enable support to encrypt calls”.

    See if that improves the situation.

  • That did it! Thanks!

    But why should that have been an issue?

    That was one of the first things I tried a few days ago. No change.

  • Richard Kenner wrote:

    The way you had things configured Asterisk was prioritizing GSM over ULAW, so until Jitsi started responding it sent GSM. This apparently upset Jitsi a little bit and caused the problem you heard (or didn’t hear, hehe). If you still want to allow GSM you can try moving the allow=gsm to below allow=ulaw. This should change the priority.

    Glad it seems to be working for you now, though!


  • I thought I might have seen something like that in the packets, but it didn’t look like it showed up in the SDP negotiations, so seemed peculiar to me. Unclear why this only happens with a static IP and not NAT, but oh well.

  • The most common problem is that the VPN network is not declared as a localnet on Asterisk so it assumes that it has to do NAT and so replaces the external IP for communication. Make sure that your VPN
    segment is in sip.conf.