[Home]

Summary:ASTERISK-24698: Asterisk 13.1.0 PJSIP over TCP gives PJSIP_ETPNOTSUITABLE
Reporter:Ian Gilmour (tuxian)Labels:
Date Opened:2015-01-16 05:43:26.000-0600Date Closed:2015-01-22 03:30:51.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_pjsip
Versions:13.1.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS release 6.6 (Final) Linux localhost.localdomain 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/LinuxAttachments:( 0) myDebugLog
Description:Hi - I raised this initially on http://forums.asterisk.org
but am getting no response there. I hope someone here can help.

I've just upgraded a local test system from Asterisk 13.0.1 to 13.1.0 and am having problems using pjsip over TCP (same config worked fine on 13.0.1).

I have 2 virtualbox VMs.
First VM runs OpenSIPS and rtpproxy.
Second VM runs Asterisk 13.1.0. chan_pjsip is configured to connect Asterisk to OpenSIPS (over TCP), with Linphone client connected to Asterisk using chan_sip (over UDP).

Asterisk registers ok with OpenSIPS over TCP on startup, but calls initated by the Linphone client (that should get forwarded on by Asterisk to OpenSIPS and then directed back to the same Asterisk) are currently failing. Call INVITE never gets forwarded to OpenSIPS by Asterisk.

I get:
{noformat}
*CLI> Dialing call 1002 <+449991002> to PJSIP/+44999123@mytrunk....
[Jan 14 16:01:16] WARNING[20909]: pjsip:0 <?>:    tsx0x7f4074009 ...Failed to send Request msg INVITE/cseq=13219 (tdta0x7f40740073e0)! err=171064 (Unsuitable transport selected (PJSIP_ETPNOTSUITABLE))
1002 <+449991002> to PJSIP/+44999123@mytrunk DialStatus: CONGESTION HangupCause: 34
1002 <+449991002> to PJSIP/+44999123@mytrunk DialStatus: CONGESTION HangupCause: 34 - using err_default
*CLI> pjsip show endpoints

Endpoint:  <Endpoint/CID.....................................>  <State.....>  <Channels.>
   I/OAuth:  <AuthId/UserName...........................................................>
       Aor:  <Aor............................................>  <MaxContact>
     Contact:  <Aor/ContactUri...............................>  <Status....>  <RTT(ms)..>
 Transport:  <TransportId........>  <Type>  <cos>  <tos>  <BindAddress..................>
  Identify:  <Identify/Endpoint.........................................................>
       Match:  <ip/cidr.........................>
   Channel:  <ChannelId......................................>  <State.....>  <Time(sec)>
       Exten: <DialedExten...........>  CLCID: <ConnectedLineCID.......>
=========================================================================================

Endpoint:  mytrunk                                              Not in use    0 of inf
   OutAuth:  mytrunk/GW1
       Aor:  mytrunk                                            0
     Contact:  mytrunk/sip:10.10.20.12:5060                     Unknown               nan
 Transport:  simpletrans               tcp      0      0  10.10.20.13:5060
  Identify:  mytrunk/mytrunk
       Match: 10.10.20.12/32
{noformat}

pjsip.conf (for TCP test) contains...
{noformat}
   ;==============TRANSPORTS

   [simpletrans]
   type=transport
   protocol=tcp
   bind=10.10.20.13

   ;===============TRUNK
   [mytrunk]
   type=registration
   transport=simpletrans
   outbound_auth=mytrunk
   outbound_proxy=sip:10.10.20.12\;transport=tcp
   server_uri=sip:10.10.20.12
   client_uri=sip:GW1@10.10.20.12
   retry_interval=60
   max_retries=1440

   [mytrunk]
   type=auth
   auth_type=userpass
   password=*******
   username=GW1

   [mytrunk]
   type=aor
   contact=sip:10.10.20.12:5060

   [mytrunk]
   type=endpoint
   transport=simpletrans
   context=externalIncoming
   disallow=all
   allow=gsm
   outbound_auth=mytrunk
   aors=mytrunk
   force_rport=yes
   direct_media=no
   media_encryption_optimistic=no

   [mytrunk]
   type=identify
   endpoint=mytrunk
   match=10.10.20.12
{noformat}
If I change pjsip.conf (& OpenSIPS) to use UDP rather than TCP it all works as expected.

Prior to the upgrade I had the same config (excluding the new media_encryption_optimistic=no option) working fine with Asterisk 13.0.1. I don't think I've changed anything in my setup.

Is this a bug or do I need some additional (Asterisk 13.1.0 specific) pjsip.conf change to get this to work over TCP?
Comments:By: Matt Jordan (mjordan) 2015-01-16 09:19:29.257-0600

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Ian Gilmour (tuxian) 2015-01-16 10:27:04.779-0600

Debug log attached, with debug + verbose set to 5, and sip & pjsip debug enabled.
By: Ian Gilmour (tuxian) 2015-01-16 10:31:43.046-0600

debug log now attached.
By: Matt Jordan (mjordan) 2015-01-19 09:56:25.431-0600

Two points:
# You have both {{chan_sip}} and {{chan_pjsip}} loaded. Make sure that you aren't binding to the same addresses/ports in both channel drivers. Doing so will have interesting results.
# Your log doesn't contain the trace logging for PJSIP. Enable that with 'pjsip set logger on' - that will show the SIP message traffic handled by PJSIP.
By: Ian Gilmour (tuxian) 2015-01-21 04:17:43.510-0600

chan_sip & chan_pjsip are binding to separate addresses in the VM (both use port 5060).
chan_sip is used for local Linphone client.
chan_pjsip is used to connect Asterisk to OpenSIPS.
I'm pretty sure pjsip logging was enabled for the log but was enabled after the registration (on TCP) has already taken place. pjsip rejects the Linphone call before sending out the INVITE. Possibly this is why you don't see any PJSIP SIP messages.
[n.b. Wireshark trace confirms the registration is indeed taking place over TCP.]

Further testing shows the Asterisk system able to receive calls from another device registered with the same OpenSIPS server. Call INVITEs coming in from OpenSIPS to Asterisk on the PJSIP managed interface (using TCP) are successfully processed by Asterisk.  (It's possible this is all I tested in the 13.0.1 version - when I though this was all working.) So I can successfully call the Linphone client (that connects via chan_sip) - I just cannot make the call in the opposite direction.

Putting gdb breakpoints on the 2 places in PJSIP where I can see the PJSIP_ETPNOTSUITABLE being returned gives me the following backtrace.

{noformat}
#0  pjsip_tpmgr_acquire_transport2 (mgr=0xabe990, type=PJSIP_TRANSPORT_UDP, remote=0x7fffe8009c98, addr_len=16, sel=0x7fffe8009e50, tdata=0x7fffe8009aa8, tp=0x7fffe8020038) at ../src/pjsip/sip_transport.c:1942
#1  0x00007ffff5778dc7 in pjsip_endpt_acquire_transport2 (endpt=0xa32ef8, type=PJSIP_TRANSPORT_UDP, remote=0x7fffe8009c98, addr_len=16, sel=0x7fffe8009e50, tdata=0x7fffe8009aa8, transport=0x7fffe8020038) at ../src/pjsip/sip_endpoint.c:1193
#2  0x00007ffff577b9a1 in stateless_send_transport_cb (token=0x7fffe8020020, tdata=0x7fffe8009aa8, sent=-70002) at ../src/pjsip/sip_util.c:1172
#3  0x00007ffff577bfe5 in stateless_send_resolver_callback (status=0, token=0x7fffe8020020, addr=0x7fffec74d6e0) at ../src/pjsip/sip_util.c:1344
#4  0x00007ffff577e141 in pjsip_resolve (resolver=0xabf1a8, pool=0x7fffe8009a00, target=0x7fffec74d930, token=0x7fffe8020020, cb=0x7ffff577bd0c <stateless_send_resolver_callback>) at ../src/pjsip/sip_resolve.c:306
#5  0x00007ffff5778cfb in pjsip_endpt_resolve (endpt=0xa32ef8, pool=0x7fffe8009a00, target=0x7fffec74d930, token=0x7fffe8020020, cb=0x7ffff577bd0c <stateless_send_resolver_callback>) at ../src/pjsip/sip_endpoint.c:1148
#6  0x00007ffff577c110 in pjsip_endpt_send_request_stateless (endpt=0xa32ef8, tdata=0x7fffe8009aa8, token=0x7fffe800ba68, cb=0x7ffff57944b7 <send_msg_callback>) at ../src/pjsip/sip_util.c:1388
#7  0x00007ffff5795145 in tsx_send_msg (tsx=0x7fffe800ba68, tdata=0x7fffe8009aa8) at ../src/pjsip/sip_transaction.c:2119
#8  0x00007ffff57958ea in tsx_on_state_null (tsx=0x7fffe800ba68, event=0x7fffec74da80) at ../src/pjsip/sip_transaction.c:2349
#9  0x00007ffff57943a6 in pjsip_tsx_send_msg (tsx=0x7fffe800ba68, tdata=0x7fffe8009aa8) at ../src/pjsip/sip_transaction.c:1727
#10 0x00007ffff579a26c in pjsip_dlg_send_request (dlg=0x7fffe4000e38, tdata=0x7fffe8009aa8, mod_data_id=13, mod_data=0x7fffe8018448) at ../src/pjsip/sip_dialog.c:1235
#11 0x00007ffff5bd92da in pjsip_inv_send_msg (inv=0x7fffe800e668, tdata=0x7fffe8009aa8) at ../src/pjsip-ua/sip_inv.c:3064
#12 0x00007fffb7353df6 in call (data=0xe3f448) at chan_pjsip.c:1578
#13 0x00000000005a7614 in ast_taskprocessor_execute (tps=0x7fffe800f528) at taskprocessor.c:769
#14 0x00000000005ae870 in execute_tasks (data=0x7fffe800f528) at threadpool.c:1157
#15 0x00000000005a7614 in ast_taskprocessor_execute (tps=0xac44e8) at taskprocessor.c:769
#16 0x00000000005af736 in threadpool_execute (arg=0x7fffd4000a18) at threadpool.c:351
#17 worker_active (arg=0x7fffd4000a18) at threadpool.c:1075
#18 worker_start (arg=0x7fffd4000a18) at threadpool.c:995
#19 0x00000000005ba2ab in dummy_start (data=<value optimized out>) at utils.c:1232
#20 0x00000034b84079d1 in start_thread () from /lib64/libpthread.so.0
#21 0x00000034b80e89dd in clone () from /lib64/libc.so.6
{noformat}

So it appears that even though Asterisk has successfully registered with OpenSIPS over TCP, PJSIP still tries to send the Call INVITE out over UDP, and this is the cause of my initial problem.

Given this and examining my previous pjsip.conf I think i was missing "outbound_proxy=sip:<opensips-ip-addr>\;transport=tcp" in the original endpoint configuration.

Certainly when I add this in to the endpoint configuration I now see PJSIP forwarding the call on to OpenSIPS over TCP.

But OpenSIPS is not able to successfully forward the call on to the client - it gives a 484 error.

A Wireshark trace shows a difference in the rURI in the 2 INVITES which may be the cause...

Failed TCP INVITE request:

{noformat}
Frame 114: 1144 bytes on wire (9152 bits), 1144 bytes captured (9152 bits) on interface 1
Linux cooked capture
Internet Protocol Version 4, Src: 192.168.1.34 (192.168.1.34), Dst: 192.168.1.39 (192.168.1.39)
Transmission Control Protocol, Src Port: 25275 (25275), Dst Port: 5060 (5060), Seq: 1, Ack: 1, Len: 1076
Session Initiation Protocol (INVITE)
   Request-Line: INVITE sip:192.168.1.39;transport=tcp SIP/2.0
       Method: INVITE
       Request-URI: sip:192.168.1.39;transport=tcp
           Request-URI Host Part: 192.168.1.39
       [Resent Packet: False]
    :
{noformat}

Successful UDP INVITE request:

{noformat}
Frame 49: 1069 bytes on wire (8552 bits), 1069 bytes captured (8552 bits) on interface 0
Ethernet II, Src: CadmusCo_84:fc:e9 (08:00:27:84:fc:e9), Dst: CadmusCo_9a:89:ab (08:00:27:9a:89:ab)
Internet Protocol Version 4, Src: 192.168.1.34 (192.168.1.34), Dst: 192.168.1.39 (192.168.1.39)
User Datagram Protocol, Src Port: 5060 (5060), Dst Port: 5060 (5060)
Session Initiation Protocol (INVITE)
   Request-Line: INVITE sip:+447775555@192.168.1.39:5060 SIP/2.0
       Method: INVITE
       Request-URI: sip:+447775555@192.168.1.39:5060
           Request-URI User Part: +447775555
           Request-URI Host Part: 192.168.1.39
           Request-URI Host Port: 5060
       [Resent Packet: False]
    :
{noformat}

So the Request-URI User part (+447775555) is missing from the TCP INVITE.

Is there a way to get Asterisk to include it in the INVITE, or do I need to handle this in OpenSIPS?

Or should I be tackling this some other way?

Thanks in advance for all the help.

By: Joshua C. Colp (jcolp) 2015-01-21 09:26:36.308-0600

Try configuring your outbound proxy like so:

outbound_proxy=sip:<opensips-ip-addr>\;transport=tcp\;lr

Strict routing, which is the default, rewrites the request URI to that of the proxy. Loose routing doesn't.
By: Ian Gilmour (tuxian) 2015-01-22 03:30:07.652-0600

Changing all outbound_proxy configurations in pjsip.conf to:

{noformat}
outbound_proxy=sip:<opensips-ip-addr>\;transport=tcp\;lr
{noformat}

did indeed fix the problem. I can now successfully make calls in both directions.

Many thanks!