PJSIP Weirdness, Or Just My Weirdness?

Home » Asterisk Users » PJSIP Weirdness, Or Just My Weirdness?
Asterisk Users 3 Comments


Oh, wise ones, ponder with me over two of the surprises that populate the universe!

I have a phone, that I sometimes cannot reach, connected via pjsip. It can call other extensions just fine, it can call out over a trunk to my cell, all is well, but getting a call? Forget it most of the time.

Here is all the config relevant to that phone:

type=aor qualify_frequency=1992

type=auth auth_type=userpass username=murftest12

type=transport protocol=udp bind=

[murftest12] ; Cisco SPA514G mac=A4:93:4C:FE:1D:A2
type=endpoint auth=murftest12
transport=transport-udp aors=murftest12
moh_suggest=default force_rport=yes rewrite_contact=yes rtp_symmetric=yes dtmf_mode=rfc4733
disallow=all allow=ulaw ; from phonetype allow=g722 ; from phonetype allow=alaw ; from phonetype allow=alaw ; from phonetype (G.729 replaced with alaw)
direct_media=no context=phone rtp_timeout=120
callerid=”Steve Murphy” <101>
mailboxes=101@murftest language=en send_rpid=yes send_pai=yes

​OK, that completes the config (I hope).

Now, when I run “pjsip show endpoints, I get:​

SFO02-HostedPBXPJSip-Dev03*CLI> pjsip show endpoints






Exten: CLCID:

Endpoint: murftest12/101 Not in use 0 of inf
InAuth: murftest12/murftest12
Aor: murftest12 2
Contact: murftest12/sip:murftest12@ 171a08228b Unavail 0.000
Contact: murftest12/sip:murftest12@ d9a15f4e35
Avail 50.514
Transport: transport-udp udp 0 0

​ Note that there are TWO Contact: entries! one Avail, the other Unavail… the show endpoints doesn’t display all the URL, but the show contacts does:

​ Contact: murftest12/sip:murftest12@ d9a15f4e35
Avail 50.514
Contact: murftest12/sip:murftest12@ 171a08228b Unavail 0.000

None of my other phones have two contacts listed…. and this phone, a cisco-spa-514, has just one sip account…

The trouble is, when I try to call it…. sometimes the INVITE is directed to the “Unavail” entry, and the call never completes. The phone doesn’t even ring then. Any ideas? I tried to get the “Unavail” entry out… I
removed it from the db, I rebooted the phone, restarted asterisk, and it is still there.


The above cisco-spa, when it calls out over the trunk, all is well, wonderful 2-way audio. But when I do the same operation from my yealink phones, I get my cell with one-way audio. It’s a classic NAT situation: the phone system is in a droplet at digital ocean, but my phones are here at home behind a NAT. I see only 3 NAT
related options:

force_rport rtp_symmetric rewrite_contact

and I set them all to “yes”, and they can call each other, but as explained, in dialing out thru a trunk, the yealinks get one-way audio…

Any more NAT options?

many thanks…


3 thoughts on - PJSIP Weirdness, Or Just My Weirdness?

  • *max_contacts = 1*
    *remove_existing = yes*
    *This should take care of mystery 1.*

    Do the phones have settings for NAT? If so, turn them on. Does your home router have a setting for SIP-ALG? If so *TURN IT OFF!!*
    Give that a shot.

  • I just resolved a similar issue with a new Yealink phone and PJSIP. It seems that Asterisk (depending on many transcoding parameters and types of calls)
    may send out a different codec on leg B than it receives on leg A. While less than optimal for the end user, this is allowed by the RFCs. Yealink doesn’t seem to handle this well. The firmware referenced in this link fixed the issue for me, as least with my T48G and DAHDI/PJSIP calls.



    Many THANKS to George and Anthony! See at the very end, my comments…

    ​George’s previous message on this thread, plus this one were very helpful in solving my problems.

    I discovered:

    1. Mystery #1 was a combination of factors:
    1. The max_contacts=1 and remove_existing=yes did in fact get rid of the
    dual contact problem! But I still could not get an INVITE to my phone.
    2. The use of qualify_frequency=60 in my aor solved the access problem.
    For some strange reason, my NAT path was shutting down before 120 sec
    for this phone, which is considerably shorter than the other phones, for
    some rather unobvious reasons.
    2. Mystery #2, as it turned out, actually was because of codec choices. The phones
    I was using were not in the list for firmware upgrades, so I had to take a different
    approach: actually standardize the codec list for phones and trunks, to all be the
    same. I did that, and all the 1-way audio problems went away.

    Thanks for the help! I hope that others who have the same problems may find this message helpful.