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-0600 | Date Closed: | 2015-01-22 03:30:51.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | 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/Linux | Attachments: | ( 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! |