PJSIP Signaling Question

Home » Asterisk Users » PJSIP Signaling Question
Asterisk Users 8 Comments

Greetings.

I am using the PJSIP driver with TLS transport, and my endpoints are SIP mobile apps operating in environments that I do not control.

I would like Asterisk to default to sending INVITES and all other SIP signals to endpoints via the existing SIP TLS connection which is already established, rather than trying to create a new TLS connection to an endpoint which is likely behind a NAT which will not allow a new inbound TCP/TLS connection.

My experience with chan_sip suggest to me that this was the default behavior, or more likely a fallback behavior, because I never had this issue before with endpoints not receiving INVITES so long as they were registered and had an open SIP control connection.

I thought that I could avoid these failed outbound connections by commenting out the “transport” option on my endpoint configurations, but tcpdump is showing me that asterisk is still trying to create *new* TLS outbound connections to my endpoints, which are failing.

Thank you for your time

Kevin

–

My simple pjsip config file:

[transport-tls]
type=transport protocol=tls bind=0.0.0.0:5061
local_net=10.50.55.0/24
external_media_address=x.x.x.x external_signaling_address=x.x.x.x cert_file=/etc/asterisk/keys/dev1.crt priv_key_file=/etc/asterisk/keys/dev1.key ca_list_file=/etc/asterisk/keys/ca.crt cipher=AES256-SHA
method=tlsv1

;===============EXTENSION 6001

[6000]
type=endpoint context=internal disallow=all allow=ulaw
;transport=transport-tls auth=auth6000
aors=6000
direct_media=no rewrite_contact=yes ; necessary if endpoint does not know/register public ip:port ice_support=no force_rport=yes rtp_symmetric=yes media_encryption=sdes

[auth6000]
type=auth auth_type=userpass password=6000
username=6000

[6000]
type=aor max_contacts=1
remove_existing=yes

;===============EXTENSION 6001

[6001]
type=endpoint context=internal disallow=all
allow=ulaw
;transport=transport-tls auth=auth6001
aors=6001
direct_media=no rewrite_contact=yes ; necessary if endpoint does not know/register public ip:port ice_support=no force_rport=yes rtp_symmetric=yes media_encryption=sdes

[auth6001]
type=auth auth_type=userpass password=6001
username=6001

[6001]
type=aor max_contacts=1
remove_existing=yes

8 thoughts on - PJSIP Signaling Question

  • This was actually an issue in pjproject which I just fixed last week. 🙂

    It’s in pjproject “trunk” so you’ll have to download and build it from their subversion repository.

    Now whether you use “transport=” or not, pjproject will look for an existing connection to the remote endpoint before attempting to create a new one.

    I tested it with the current Asterisk 13 branch and I *think* it’ll work with recent Asterisk releases as well. If it doesn’t, let me know.

  • Interesting, thanks George. I pulled Asterisk 13 from git and the new pjproject from the SVN and will test accordingly .

    I have a few more questions about PJSIP in Asterisk 13:

    1. Is there any way to list current ongoing calls and see what codecs are being used in the RTP streams? With chan_sip, “sip show channels” did this.

    2. Also with a PJSIP initiated call, is there a way to see how man RTP packets have been sent and received for the call , I am debugging some intermittent 1-way and no-way audio on calls , and I am having trouble figuring out fi it is the client, firewall, or Asterisk/pjsip that is the culprit .

    Regards,

    Kevin Long

  • ​Yeah, actually you do need Asterisk 13 from git because pjproject deprecated an api in trunk and we only handle that in the current git 13
    branch.​

    ​Unfortunately, no to both (at least that I’m aware of). I remember looking at the channel stats a long while back and for some reason didn’t go any further. I can re-look.

  • Thanks George I appreciate the info . Being able to see what codec is in use for call in progress is very handy sometimes.

    As far as the RTP stats goes, I see there is some info with “rtp” and “rtcp” commands which can be useful for troubleshooting. A running tally of # packets or bandwidth used would be awesome in along with the codec in “pjsip show channels” or something like that.

    Im not certain, but I think the TLS signalling problem from this email may be happening to me again after patching for another pjsip/NAT issue which was with the external_media_address not working and the internal IP being sent in the SDP from asterisk – I applied this patch to the codebase and recompiled I am seeing the TLS “new transport” issue again , I think.

    Regards,

    Kevin Long

  • ​I’ve lost track of who’s applying what patches to ​which codebase. 🙂

    Which patch did you apply for “external_media_address not working”?

  • –Apple-Mail-E86A02DC-6561-43BE-A2F5-49AB0BD7D046
    Content-Type: text/plain;
    charset=utf-8
    Content-Transfer-Encoding: base64

    SGkgR2VvcmdlIHRoZSBwYXRjaCB3YXMgZnJvbSBoZXJlICwgeW91IHdyb3RlIGl0IEkgYmVsaWV2
    ZSAuIEkgcHVsbGVkIGFzdGVyaXNrIDEzIGZyb20gZ2l0LCBhcHBseSB0aGlzIHBhdGNoIHdoaWNo IGZpeGVkIFJUUCBpc3N1ZSAsIGJ1dCBJIHRoaW5rIHRsYSB0cmFuc3BvcnQgaXNzdWUgY2FtZSBi YWNrIGZvciBtZSAuIA0KDQpodHRwczovL2dlcnJpdC5hc3Rlcmlzay5vcmcvIy9jLzIzNDYvDQoN
    ClRoYW5rIHlvdQ0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCj4gT24gTWFyIDQsIDIwMTYsIGF0
    IDEyOjAxIEFNLCBHZW9yZ2UgSm9zZXBoIDxnZW9yZ2Uuam9zZXBoQGZhaXJ2aWV3NS5jb20+IHdy b3RlOg0KPiANCj4gDQo+IA0KPj4gT24gVGh1LCBNYXIgMywgMjAxNiBhdCA4OjI1IFBNLCBLZXZp biBMb25nIDxrZXZpbi5sb25nQGhhbG9wcml2YWN5LmNvbT4gd3JvdGU6DQo+PiANCj4+IFRoYW5r cyBHZW9yZ2UgSSBhcHByZWNpYXRlIHRoZSBpbmZvIC4gIEJlaW5nIGFibGUgdG8gc2VlIHdoYXQg Y29kZWMgaXMgaW4gdXNlIGZvciBjYWxsIGluIHByb2dyZXNzIGlzIHZlcnkgaGFuZHkgc29tZXRp bWVzLg0KPj4gDQo+PiBBcyBmYXIgYXMgdGhlIFJUUCBzdGF0cyBnb2VzLCAgSSBzZWUgdGhlcmUg aXMgc29tZSBpbmZvIHdpdGgg4oCccnRw4oCdIGFuZCDigJxydGNw4oCdIGNvbW1hbmRzIHdoaWNo IGNhbiBiZSB1c2VmdWwgZm9yIHRyb3VibGVzaG9vdGluZy4gQSBydW5uaW5nIHRhbGx5IG9mICMg cGFja2V0cyBvciBiYW5kd2lkdGggdXNlZCB3b3VsZCBiZSBhd2Vzb21lIGluIGFsb25nIHdpdGgg dGhlIGNvZGVjIGluICJwanNpcCBzaG93IGNoYW5uZWxzIiBvciBzb21ldGhpbmcgbGlrZSB0aGF0
    Lg0KPj4gDQo+PiANCj4+IEltIG5vdCBjZXJ0YWluLCBidXQgSSB0aGluayB0aGUgVExTIHNpZ25h bGxpbmcgcHJvYmxlbSBmcm9tIHRoaXMgZW1haWwgbWF5IGJlIGhhcHBlbmluZyB0byBtZSBhZ2Fp biBhZnRlciBwYXRjaGluZyBmb3IgYW5vdGhlciBwanNpcC9OQVQgaXNzdWUgd2hpY2ggd2FzIHdp dGggdGhlIGV4dGVybmFsX21lZGlhX2FkZHJlc3Mgbm90IHdvcmtpbmcgYW5kIHRoZSBpbnRlcm5h bCBJUCBiZWluZyBzZW50IGluIHRoZSBTRFAgZnJvbSBhc3RlcmlzayAtIEkgYXBwbGllZCB0aGlz IHBhdGNoIHRvIHRoZSBjb2RlYmFzZSBhbmQgcmVjb21waWxlZCBJIGFtIHNlZWluZyB0aGUgVExT
    IOKAnG5ldyB0cmFuc3BvcnTigJ0gIGlzc3VlIGFnYWluICwgSSB0aGluay4NCj4gDQo+IOKAi0kn dmUgbG9zdCB0cmFjayBvZiB3aG8ncyBhcHBseWluZyB3aGF0IHBhdGNoZXMgdG8g4oCLd2hpY2gg Y29kZWJhc2UuIDopDQo+IA0KPiBXaGljaCBwYXRjaCBkaWQgeW91IGFwcGx5IGZvciAiZXh0ZXJu YWxfbWVkaWFfYWRkcmVzcyBub3Qgd29ya2luZyI/DQo+IA0KPiAgDQo+PiANCj4+IFJlZ2FyZHMs DQo+PiANCj4+IEtldmluIExvbmcNCj4+IC0tDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IC0tIEJhbmR3
    aWR0aCBhbmQgQ29sb2NhdGlvbiBQcm92aWRlZCBieSBodHRwOi8vd3d3LmFwaS1kaWdpdGFsLmNv bSAtLQ0KPj4gTmV3IHRvIEFzdGVyaXNrPyBKb2luIHVzIGZvciBhIGxpdmUgaW50cm9kdWN0b3J5
    IHdlYmluYXIgZXZlcnkgVGh1cnM6DQo+PiAgICAgICAgICAgICAgICBodHRwOi8vd3d3LmFzdGVy aXNrLm9yZy9oZWxsbw0KPj4gDQo+PiBhc3Rlcmlzay11c2VycyBtYWlsaW5nIGxpc3QNCj4+IFRv IFVOU1VCU0NSSUJFIG9yIHVwZGF0ZSBvcHRpb25zIHZpc2l0Og0KPj4gICAgaHR0cDovL2xpc3Rz LmRpZ2l1bS5jb20vbWFpbG1hbi9saXN0aW5mby9hc3Rlcmlzay11c2Vycw0KPiANCj4gLS0gDQo+
    IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiAtLSBCYW5kd2lkdGggYW5kIENvbG9jYXRpb24gUHJvdmlkZWQgYnkg aHR0cDovL3d3dy5hcGktZGlnaXRhbC5jb20gLS0NCj4gTmV3IHRvIEFzdGVyaXNrPyBKb2luIHVz IGZvciBhIGxpdmUgaW50cm9kdWN0b3J5IHdlYmluYXIgZXZlcnkgVGh1cnM6DQo+ICAgICAgICAg ICAgICAgaHR0cDovL3d3dy5hc3Rlcmlzay5vcmcvaGVsbG8NCj4gDQo+IGFzdGVyaXNrLXVzZXJz IG1haWxpbmcgbGlzdA0KPiBUbyBVTlNVQlNDUklCRSBvciB1cGRhdGUgb3B0aW9ucyB2aXNpdDoN
    Cj4gICBodHRwOi8vbGlzdHMuZGlnaXVtLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2FzdGVyaXNrLXVz ZXJzDQo
    –Apple-Mail-E86A02DC-6561-43BE-A2F5-49AB0BD7D046
    Content-Type: text/html;
    charset=utf-8
    Content-Transfer-Encoding: base64

    PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0
    L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPjxkaXY+SGkgR2Vv cmdlIHRoZSBwYXRjaCB3YXMgZnJvbSBoZXJlICwgeW91IHdyb3RlIGl0IEkgYmVsaWV2ZSAuIEkg cHVsbGVkIGFzdGVyaXNrIDEzIGZyb20gZ2l0LCBhcHBseSB0aGlzIHBhdGNoIHdoaWNoIGZpeGVk IFJUUCBpc3N1ZSAsIGJ1dCBJIHRoaW5rIHRsYSB0cmFuc3BvcnQgaXNzdWUgY2FtZSBiYWNrIGZv ciBtZSAuJm5ic3A7PC9kaXY+PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YnI+PC9kaXY+
    PGRpdiBpZD0iQXBwbGVNYWlsU2lnbmF0dXJlIj48YSBocmVmPSJodHRwczovL2dlcnJpdC5hc3Rl cmlzay5vcmcvIy9jLzIzNDYvIj5odHRwczovL2dlcnJpdC5hc3Rlcmlzay5vcmcvIy9jLzIzNDYv PC9hPjwvZGl2PjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+PGJyPjwvZGl2PjxkaXYgaWQ9
    IkFwcGxlTWFpbFNpZ25hdHVyZSI+VGhhbmsgeW91PGJyPjxicj5TZW50IGZyb20gbXkgaVBob25l PC9kaXY+PGRpdj48YnI+T24gTWFyIDQsIDIwMTYsIGF0IDEyOjAxIEFNLCBHZW9yZ2UgSm9zZXBo ICZsdDs8YSBocmVmPSJtYWlsdG86Z2VvcmdlLmpvc2VwaEBmYWlydmlldzUuY29tIj5nZW9yZ2Uu am9zZXBoQGZhaXJ2aWV3NS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1
    b3RlIHR5cGU9ImNpdGUiPjxkaXY+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
    ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjxkaXYgZGlyPSJsdHIiPjxkaXYgY2xhc3M9
    ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTonYXJpYWwgbmFycm93JyxzYW5zLXNl cmlmIj48YnI+PC9kaXY+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxicj48ZGl2IGNsYXNzPSJn bWFpbF9xdW90ZSI+T24gVGh1LCBNYXIgMywgMjAxNiBhdCA4OjI1IFBNLCBLZXZpbiBMb25nIDxz cGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmtldmluLmxvbmdAaGFsb3ByaXZhY3ku Y29tIiB0YXJnZXQ9Il9ibGFuayI+a2V2aW4ubG9uZ0BoYWxvcHJpdmFjeS5jb208L2E+Jmd0Ozwv c3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1h cmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdC13aWR0aDoxcHg7Ym9yZGVyLWxlZnQt c3R5bGU6c29saWQ7Ym9yZGVyLWxlZnQtY29sb3I6cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxl ZnQ6MWV4Ij48YnI+DQpUaGFua3MgR2VvcmdlIEkgYXBwcmVjaWF0ZSB0aGUgaW5mbyAuJm5ic3A7
    IEJlaW5nIGFibGUgdG8gc2VlIHdoYXQgY29kZWMgaXMgaW4gdXNlIGZvciBjYWxsIGluIHByb2dy ZXNzIGlzIHZlcnkgaGFuZHkgc29tZXRpbWVzLjxicj4NCjxicj4NCkFzIGZhciBhcyB0aGUgUlRQ
    IHN0YXRzIGdvZXMsJm5ic3A7IEkgc2VlIHRoZXJlIGlzIHNvbWUgaW5mbyB3aXRoIOKAnHJ0cOKA
    nSBhbmQg4oCccnRjcOKAnSBjb21tYW5kcyB3aGljaCBjYW4gYmUgdXNlZnVsIGZvciB0cm91Ymxl c2hvb3RpbmcuIEEgcnVubmluZyB0YWxseSBvZiAjIHBhY2tldHMgb3IgYmFuZHdpZHRoIHVzZWQg d291bGQgYmUgYXdlc29tZSBpbiBhbG9uZyB3aXRoIHRoZSBjb2RlYyBpbiAicGpzaXAgc2hvdyBj aGFubmVscyIgb3Igc29tZXRoaW5nIGxpa2UgdGhhdC48YnI+DQo8YnI+DQo8YnI+DQpJbSBub3Qg Y2VydGFpbiwgYnV0IEkgdGhpbmsgdGhlIFRMUyBzaWduYWxsaW5nIHByb2JsZW0gZnJvbSB0aGlz IGVtYWlsIG1heSBiZSBoYXBwZW5pbmcgdG8gbWUgYWdhaW4gYWZ0ZXIgcGF0Y2hpbmcgZm9yIGFu b3RoZXIgcGpzaXAvTkFUIGlzc3VlIHdoaWNoIHdhcyB3aXRoIHRoZSBleHRlcm5hbF9tZWRpYV9h ZGRyZXNzIG5vdCB3b3JraW5nIGFuZCB0aGUgaW50ZXJuYWwgSVAgYmVpbmcgc2VudCBpbiB0aGUg U0RQIGZyb20gYXN0ZXJpc2sgLSBJIGFwcGxpZWQgdGhpcyBwYXRjaCB0byB0aGUgY29kZWJhc2Ug YW5kIHJlY29tcGlsZWQgSSBhbSBzZWVpbmcgdGhlIFRMUyDigJxuZXcgdHJhbnNwb3J04oCdJm5i c3A7IGlzc3VlIGFnYWluICwgSSB0aGluay48YnI+PC9ibG9ja3F1b3RlPjxkaXY+PGJyPjwvZGl2
    PjxkaXY+PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5Oidhcmlh bCBuYXJyb3cnLHNhbnMtc2VyaWYiPuKAi0kndmUgbG9zdCB0cmFjayBvZiB3aG8ncyBhcHBseWlu ZyB3aGF0IHBhdGNoZXMgdG8g4oCLd2hpY2ggY29kZWJhc2UuIDopPC9kaXY+PGRpdiBjbGFzcz0i Z21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OidhcmlhbCBuYXJyb3cnLHNhbnMtc2Vy aWYiPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1p bHk6J2FyaWFsIG5hcnJvdycsc2Fucy1zZXJpZiI+V2hpY2ggcGF0Y2ggZGlkIHlvdSBhcHBseSBm b3IgIjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTphcmlhbCxzYW5zLXNlcmlmIj5leHRlcm5hbF9t ZWRpYV9hZGRyZXNzIG5vdCB3b3JraW5nIj88L3NwYW4+PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj4mbmJzcDs8L2Rpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQtd2lkdGg6MXB4O2JvcmRlci1s ZWZ0LXN0eWxlOnNvbGlkO2JvcmRlci1sZWZ0LWNvbG9yOnJnYigyMDQsMjA0LDIwNCk7cGFkZGlu Zy1sZWZ0OjFleCI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCktldmluIExvbmc8YnI+LS08
    YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQotLSBCYW5kd2lkdGggYW5kIENvbG9jYXRpb24gUHJvdmlk ZWQgYnkgPGEgaHJlZj0iaHR0cDovL3d3dy5hcGktZGlnaXRhbC5jb20iIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly93d3cuYXBpLWRpZ2l0YWwuY29tPC9hPiAtLTxicj4N
    Ck5ldyB0byBBc3Rlcmlzaz8gSm9pbiB1cyBmb3IgYSBsaXZlIGludHJvZHVjdG9yeSB3ZWJpbmFy IGV2ZXJ5IFRodXJzOjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDs8YSBocmVmPSJodHRwOi8vd3d3LmFzdGVyaXNrLm9yZy9oZWxsbyIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3d3dy5hc3Rlcmlzay5vcmcv aGVsbG88L2E+PGJyPg0KPGJyPg0KYXN0ZXJpc2stdXNlcnMgbWFpbGluZyBsaXN0PGJyPg0KVG8g VU5TVUJTQ1JJQkUgb3IgdXBkYXRlIG9wdGlvbnMgdmlzaXQ6PGJyPg0KJm5ic3A7ICZuYnNwOzxh IGhyZWY9Imh0dHA6Ly9saXN0cy5kaWdpdW0uY29tL21haWxtYW4vbGlzdGluZm8vYXN0ZXJpc2st dXNlcnMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9saXN0cy5kaWdp dW0uY29tL21haWxtYW4vbGlzdGluZm8vYXN0ZXJpc2stdXNlcnM8L2E+PGJyPjwvYmxvY2txdW90
    ZT48L2Rpdj48YnI+PC9kaXY+PC9kaXY+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+PGRpdj48c3Bhbj4tLSA8L3NwYW4+PGJyPjxzcGFuPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48YnI+PHNwYW4+LS0gQmFuZHdpZHRoIGFuZCBDb2xvY2F0aW9uIFByb3ZpZGVkIGJ5IDxh IGhyZWY9Imh0dHA6Ly93d3cuYXBpLWRpZ2l0YWwuY29tIj5odHRwOi8vd3d3LmFwaS1kaWdpdGFs LmNvbTwvYT4gLS08L3NwYW4+PGJyPjxzcGFuPk5ldyB0byBBc3Rlcmlzaz8gSm9pbiB1cyBmb3Ig YSBsaXZlIGludHJvZHVjdG9yeSB3ZWJpbmFyIGV2ZXJ5IFRodXJzOjwvc3Bhbj48YnI+PHNwYW4+
    ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxhIGhyZWY9Imh0dHA6Ly93d3cuYXN0ZXJpc2su b3JnL2hlbGxvIj5odHRwOi8vd3d3LmFzdGVyaXNrLm9yZy9oZWxsbzwvYT48L3NwYW4+PGJyPjxz cGFuPjwvc3Bhbj48YnI+PHNwYW4+YXN0ZXJpc2stdXNlcnMgbWFpbGluZyBsaXN0PC9zcGFuPjxi cj48c3Bhbj5UbyBVTlNVQlNDUklCRSBvciB1cGRhdGUgb3B0aW9ucyB2aXNpdDo8L3NwYW4+PGJy PjxzcGFuPiAmbmJzcDsmbmJzcDs8YSBocmVmPSJodHRwOi8vbGlzdHMuZGlnaXVtLmNvbS9tYWls bWFuL2xpc3RpbmZvL2FzdGVyaXNrLXVzZXJzIj5odHRwOi8vbGlzdHMuZGlnaXVtLmNvbS9tYWls bWFuL2xpc3RpbmZvL2FzdGVyaXNrLXVzZXJzPC9hPjwvc3Bhbj48L2Rpdj48L2Jsb2NrcXVvdGU+
    PC9ib2R5PjwvaHRtbD4
    –Apple-Mail-E86A02DC-6561-43BE-A2F5-49AB0BD7D046

  • ​Oh, that one, OK. ​ It should be merged now so if you ‘git pull’ on 13
    now, you should get it. The transport re-use issue was in pjproject so is it possible that you’re not compiling against the latest trunk?

  • I can’t quite figure it out , I went ahead and pulled everything yet again, and I made sure to delete everything related to pjproject from my system, all the PJ lib and include files that were in /usr/lib/ , I pulled pjproject from svn , pulled asterisk code from gerrit, recompiled everything, but still I think new TLS transports are being made which fail in my NAT scenarios . I check with:

    tcpdump -i any src host 10.50.55.10 and ‘tcp[13] & 2 != 0’

    I see tcpdump print a new tcp SYN packet when I try to make a call between endpoints and also when Asterisk tries to send OPTIONS command to the endpoint .

    From my endpoints, I can call the “echo” applications and the call works fine, but I cannot call from one endpoint to another endpoint , even though they are both egistered. It does not say “unavailable’ or anything, I see in the pjsip log that an INVITE is “sent” , but I think the logger is just showing me that the INVITE message has been created, but it never reaches the endpoint because of the new TLS connection failing because of the NAT. Eventually, the call times out with a 408 error in the pjsip log.

    I also see some log entries:
    [Mar 4 12:29:10] DEBUG[16225] pjsip: tlsc0x7f311400 TLS connect() error: Connection timed out [code=120110]
    [Mar 4 12:29:29] DEBUG[16225] pjsip: tlsc0x7f311400 TLS connect() error: Connection timed out [code=120110]

    Just to be clear I am getting pjproject like so :
    svn co http://svn.pjsip.org/repos/pjproject/trunk

    and asterisk :
    git clone -b 13 http://gerrit.asterisk.org/asterisk

    then I go to pjproject directory, create a site_config.h file (to increase TLS connectors and set other options recommended on Wiki)

    configure pjproject with the following options:

    ./configure –prefix=/usr –enable-shared –disable-sound –disable-resample –disable-video –disable-opencore-amr –with-external-srtp

    Then go to asterisk directory

    make clean; make distclean; ./boostrap.sh ; ./configure; make menuselect; make; make install;