drachtio / drachtio-server Goto Github PK

View Code? Open in Web Editor NEW

222.0 29.0 86.0 320.83 MB

A SIP call processing server that can be controlled via nodejs applications

Home Page: https://drachtio.org

License: MIT License

Shell 5.60% C++ 82.39% Makefile 0.63% M4 4.08% Dockerfile 0.19% JavaScript 7.11%

sip drachtio drachtio-srf nodejs

drachtio-server's Introduction

drachtio-server [

drachtio-server is a SIP server that is built on the sofia SIP stack. It provides a high-performance SIP engine that can be controlled by client applications written in pure Javascript running on node.js .

The nodejs module that you can use to create applications controlling the server is called drachtio-srf.

Docker

A docker image can be found here.

The drachtio/drachtio-server:latest tagged image is kept current with the tip of the main branch, which is probably what you want.

Ansible

An ansible role can be found here for building drachtio using ansible.

Building from source

Note: The build requires libcurl and tcmalloc. These can can be installed on debian as follows

sudo apt install libcurl4-openssl-dev

All other third-party dependencies can be found under $(srcdir)/deps. These include boost and the sofia sip stack. sofia is included as git submodules in this project.

After installing libcurl, do as follows:

git clone --depth=50 --branch=main https://github.com/drachtio/drachtio-server.git && cd drachtio-server
git submodule update --init --recursive
./autogen.sh
mkdir build && cd $_
../configure CPPFLAGS='-DNDEBUG'
make
sudo make install

Building with tcmalloc

If you want to build with tcmalloc, which is a faster implementation of memory management, install libgoogle-perftools-dev and then adding a configure option:

sudo apt install libgoogle-perftools-dev

# run autotools and create build directory as shown above
../configure --enable-tcmalloc=yes CPPFLAGS='-DNDEBUG'

Platform support and dependencies

drachtio-server has been most heavily deployed on debian buster (10) but has undergone at least some level of testing on the following platforms:

Debian 8, 9, 10, 11
Centos 6.x
Ubuntu 10, 20
Fedora 20
Linux Mint
Mac OSX (10.9.2+)

It can also be built on arm64 platforms.

The following libraries are required to build:

gcc and c++ compilers
libssl-dev
libtool
autoconf
automake
zlib1g-dev

Installing

The output of the build process is an executable named 'drachtio'. You can run sudo make install to copy it into /usr/local/bin, or you can run the executable directly from the build directory. If run with no command line parameters, it will look for a configuration file in /etc/drachtio.conf.xml; alternatively you can specify the config file location by starting the executable with the -f option (e.g. ./drachtio -f ../drachtio.conf.xml).

The server can be run as a daemon process by running with the --daemon command line parameter.

To see all of the command line options, run drachtio -h.

The process can be installed as a Linux systemd or init script using the example script that can be found in drachtio.service or drachtio-init-script.

Configuring

drachtio can be configured via a configuration file (see sample config), environment variables, or command-line arguments. The order of precedence is that command-line arguments will dictate, if provided; otherwise environment variables (if provided), and last of all the configuration file. This is on a parameter-by-parameter basis; i.e. one configuration option may be provided by environment variables, some others by command-line args, and the rest by a configuration file.

Overview

The configuration settings are described below as provided in the configuration file, with notes as to the equivalent command line or environment variables (if available).

SIP

The most important configuration parameters specify which sip address(es) and protocols to listen on/for. drachtio can listen on multiple addresses/ports/protocols simultaneously, Example config file section:

<drachtio>
  <sip>
    <contacts>
      <contact>sip:172.28.0.1:5060;transport=udp,tcp</contact>
      <contact>sip:172.28.0.1:5080;transport=udp,tcp</contact>
    </contacts>

or, via command line:

drachtio --contact "sip:172.28.0.1:5060;transport=udp,tcp" \
   --contact "sip:172.28.0.1:5080;transport=udp,tcp"

Note: there is currently no option to specify these settings via environment variables.

Optionally, you can also specify an external ip address to associate with a sip contact, if the server is set up to masquerade or is otherwise assigned a public IP address that it does not know about. You can also specify the local network CIDR associated with a sip address, which is useful in scenarios where a server is connected to both public and private networks. See the sample configuration file for more details on this.

Admin port

The server listens for TCP (or, if desired, TLS) connections (e.g. inbound connections) from node.js applications on a specified address and port.

<drachtio>
  <admin port="9022" tls-port="9023" secret="cymru">127.0.0.1</admin>

drachtio --port 9022 --tls-port 9023 # address defaults to 0.0.0.0

DRACHTIO_ADMIN_TCP_PORT=9022 DRACHTIO_ADMIN_TLS_PORT=9023 drachtio

Logging

Log files can be written to the console, to a file, or to syslog (or any or all of the above simultaneously).

In a standard installation, log files are written to /var/log/drachtio with the current drachtio.log found there, and archived logs in the archive sub-folder. drachtio will automically truncate and roll logs based on the parameters specified in the config file.

In a container implementation, console based logging is more useful, and is the default when all arguments are supplied on the command line. Log levels for both drachtio and the underlying sofia sip stack can be specified:

<drachtio>
  <logging>
    <sofia-loglevel>3</sofia-loglevel> <!-- 0-9 -->
    <loglevel>info</loglevel> <!-- notice, warning, error, info, debug -->

drachtio --loglevel info --sofia-loglevel 3

DRACHTIO_LOGLEVEL=info DRACHTIO_SOFIA_LOGLEVEL=3 drachtio

Monitoring

Homer

drachtio can send encapsulated SIP messages to Homer for reporting.

<drachtio>
  <sip>
    <capture-server port="9060" hep-version="3" id="101">172.28.0.23</capture-server>

or, using command-line arguments

drachtio --homer 172.28.0.23 --homer-id 101  # defaults to HEP3 and UDP

or, using environment variables

DRACHTIO_HOMER_ADDRESS=172.28.0.23 DRACHTIO_HOMER_PORT=9060 DRACHTIO_HOMER_ID=101 drachtio

Prometheus.io

drachtio can be configured to report metrics to Prometheus.

<drachtio>
  <monitoring>
    <prometheus port="9060">172.28.0.23</prometheus>
  </monitoring>

or, using command line arguments

drachtio --prometheus-scrape-port 9090

drachtio --prometheus-scrape-port "0.0.0.0:9090"

or, using environment variables

DRACHTIO_PROMETHEUS_SCRAPE_PORT=9090 drachtio

For details on the specified metrics exposed, see here.

Fail2ban integration

To install fail2ban on a drachtio server, refer to this ansible role which installs and configures fail2ban with a filter for drachtio log files.

drachtio-server's People

Contributors

Stargazers

Watchers

Forkers

opendena valenti1234 metallicamfg gitter-badger xxxman2008 digideskio enterstudios switch168 newtondev salihy yuwonodarmawan csiwek ghafran benlai2018 calvet27 richnew10 chatbotszakerto invoxio danias saisyam shaddy1884 radicaldrew mikeatmerculia baonq-me connection-telecom jbasg jrvaghela72 tsearle geekbleek ajithdesilva hiyainc-oss pippistro pippistro-fedro sammymdp ethanbrooks oraad jongsix ca4ti tungnguyen2106 whitepiratebaku avoylenko ciscomonkey joelact reloadbrain daners harold-yh modernstar pauloroncon rnshah9 ghenry technohood apetcho wqqas1 xvmvx xquanluu dnygate babblevoice danieludy ccppprogrammer shanehughes1990 jamison413 usternes consort-digital dboag cstar carlitosandraus ythyty koodeyo-softphone orgads phamhieptel4vn rsp9 sumit-kumar-iitm cwysong85 byoungdale namdoel1412 wasubire newmedia2 oliverv spointer midshipman prawee anhnv hyavari izahirclemencia dualtonecomms achernetsov

drachtio-server's Issues

Crash happening on startup on loading regex code

Hello Dave! So nice your work on this. We are start using it in a very important project at Atos group.

I just downloaded the last version and checked out the latest from develop. Compilation runs fine... But a crash happens when starting the drachtio-server. Please look the attached picture:

I was having no problem on my previous compilation (that I cloned some weeks ago). By comparing the code, I saw that you made changes on it :-), so I am assuming that a new bug was introduced.

Can you please address that? Thank you so much!

failed to find transactionId and crash

Drachtio-server crashes every 8-9 days, I inspected logs, only thing I can find is this line:
You can see that after this line, it stops logging till service/system restart.

2018-07-17 17:13:58.517453 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - failed to find transactionId 79aacf0b-359e-4217-9e0c-112940787577

logs:
log.zip

Feature Request: add options to specify admin port, IP and secret on command line

Reviewing the code I only see the config class referencing the admin IP, port and secret values in the XML config file:

<admin port="9022" secret="cymru">127.0.0.1</admin>

When running a Docker container it is less desirable to hard-code these types of properties in a configuration file that requires complex configuration (file) management. This is especially true when setting these types of properties in a very dynamic environment with service discovery.

Ideally, these values would be referenced/passed via environment variables or the command line parameters. This concept is similar to the way that we can pass --contact and --external-ip config parameters.

Perhaps (very likely!) I'm overlooking something in the code but I don't see any way to perform this type of configuration.

Thanks for releasing such a great project to the open source world!

Regards,
Lucas

Incorrect destination subnet for proxy request

In a related question to issue #23, if the drachtio-server is listening on multiple network interfaces, say a host IP of 192.168.1.1 and a docker network IP of 172.22.0.1, the following happens in the proxy invite scenario using drachtio-srf:

[email protected] -> 172.22.0.1 (client A sends INVITE to client B via the proxy)
172.22.0.1 -> 172.22.0.2 (100 Trying back to client A)
192.168.1.1 -> [email protected] (proxy forwards INVITE to client B)

There is no routing from 192.168.1.1 to 172.22.0.3 so client B never sees the request.

Expectation: drachtio-server should be forwarding the INVITE using the 172.22.0.1 interface to a client on the 172.22.0.* subnet.

As a workaround I can limit the interfaces that drachtio-server listens on to just 172.22.0.1.

Bind to Specific Interface

Is it possible to bind the server to a specific interface? Right now the Server chooses the wrong interface for outgoing UDP (in a specific scenario with our internal phones).

Stereo sound with two channels (Left and Right) getting mixed

Hello,

I have used the project you helped me evolve to include it in an application I am developping. I don't experience signaling problems anymore thanks to your help but my issue is a bit more sophisticated.

I am using drachtio to return a stereo sound to a SIP codec. The sound consists of two channels left and right with some music on the left channel and some voice in the right channel. Somewhere between the generation of the stereo sound and the reception in the codec the two channels get mixed.
Here is the architecture :

I tried to eliminate all possibilities one by one. I tried to reproduce with kurento and VLC the same kurento architecture I used when making SIP calls, just replacing the SIP layer by VLC (a webrtcendpoint and a rtpendpoint). The two channels were separated as they should be.

I tried to use a professsional codec at the reception, which I am sure is capable of recepting stereo. I checked with a professional that the reception is indeed in stereo and adjusted the sdp accordingly (sprop-stereo=1 in the sdp offer and in the sdp answer). The two channels were mixed.

The only source left of this problem is the drachtio layer. Have you faced such a problem already ? Is there a parameter I should adjust to have a stereo sound with two separated channels ?

Thank you for your help,

Guillaume Prat

clear client data when client disconnects

particularly in outbound mode, when a client disconnects we need to clear associate app and net transactions. There should never be data in those maps when there are no clients connected as below

2017-09-19 13:17:10.345075 ClientController storage counts
2017-09-19 13:17:10.345082 ----------------------------------
2017-09-19 13:17:10.345089 m_clients size:                                                  0
2017-09-19 13:17:10.345095 m_services size:                                                 0
2017-09-19 13:17:10.345102 m_request_types size:                                            0
2017-09-19 13:17:10.345109 m_map_of_request_type_offsets size:                              0
2017-09-19 13:17:10.345116 m_mapDialogs size:                                               0
2017-09-19 13:17:10.345123 m_mapNetTransactions size:                                       20
2017-09-19 13:17:10.345130 m_mapAppTransactions size:                                       3

DrachtIO and Homer

Hi,

we are trying to get get HEP running. We had installed Homer5-Docker and the HEP3 Packages are reaching the container (port 9060).
But it seems homer does not even recognize these packages

Do you have a defined a enviroment in which homer integration does work?

drachtio-server with fsmrf (conference)

Hi Dave,

Happy new year for starter, hope you had a good new year.

Okay so I'm trying to develop a conferencing solution using fsmrf and I'm getting a crash when endpoint.destroy() is called.
crash log here: https://gist.github.com/andrewvmail/82139730fbd4b6593af947c0278e6fdc

I'm on the v0.7.3-61-gdc9814be1 (nat-handling-branch)

The crash happens during development. The setup is as follows:

drachtio-server running on a mac host computer
drachtio freeswitch docker container running on the mac docker virtual machine (192.168.99.100)
I made a slight modification to mrf.xml so that sip-ip, tp-ip, ext-sip-ip, ext-rtp-ip is binded to the above vm ip instead of the containers ip address
the client is running on the same computer the server is running connected via websocket

I can create conference and connect to it, but dialog.destroy() crash the drachtio server.

Using this config file:

<!-- https://github.com/davehorton/drachtio-server/blob/master/drachtio.conf.xml -->
<drachtio>
    <admin port="9022" secret="cymru">0.0.0.0</admin>
    <sip>
        <contacts>
            <contact>sip:0.0.0.0:5040;transport=tcp,udp</contact>
            <contact>sip:0.0.0.0:80;transport=ws</contact>
            <contact>sips:0.0.0.0;transport=tls</contact>
            <contact>sips:0.0.0.0:443;transport=wss</contact>
        </contacts>
        <tls>
            <key-file>/Users/andrew/projects/kosmos/certs/wildcard/privkey.pem</key-file>
            <cert-file>/Users/andrew/projects/kosmos/certs/wildcard/cert.pem</cert-file>
            <chain-file>/Users/andrew/projects/kosmos/certs/wildcard/chain.pem</chain-file>
        </tls>
        <spammers action="reject" tcp-action="discard">
            <header name="User-Agent">
                <value>sip-cli</value>
                <value>sipcli</value>
                <value>friendly-scanner</value>
            </header>
            <header>
                <value>sipvicious</value>
            </header>
        </spammers>
    </sip>
    <cdrs>false</cdrs>
    <logging>
        <console/>
        <sofia-loglevel>9</sofia-loglevel>
        <loglevel>debug</loglevel>
    </logging>
</drachtio>

crash during call when websocket UAs is refreshed at the same time

I believe this is an edge case. The frontend framework that i use refreshes the browser whenever i make change to source. When I'm testing a call and forgot to hangup and both browser reloads at the same time and i try to register again this happens, but it doesn't happen all the time... both uas and server component is running all on the same machine.

2018-09-30 15:03:05.455643 Client::processMessage - got request with 4 tokens
2018-09-30 15:03:05.455676 Client::processMessage - request id af81efaf-0e6e-419b-ab36-412798b0e05c, request type: sip transaction id: fc7c1ae1-3b30-40b3-b59d-3ed9034feb14, dialog id: 
2018-09-30 15:03:05.455707 ClientController::addApiRequest: clientMsgId af81efaf-0e6e-419b-ab36-412798b0e05c; size: 2
2018-09-30 15:03:05.456399 Client::read_handler read: 4b8c4db0-ec15-431f-8b40-69d5d08a8bf1|sip|c3ff6d0b-bec1-47c7-8013-066b1a6cdf1b|
SIP/2.0 200 OK
Call-ID: lriabj2uc92o10iomkdsjp
cseq: 8978 REGISTER
from: <sip:[email protected]>;tag=dd3sr2r041
to: <sip:[email protected]>
Content-Length: 0
contact: <sip:[email protected];transport=ws>;reg-id=1;+sip.instance="<urn:uuid:e220459a-56e7-4d81-b322-0956d85a0ffe>";expires=0



2018-09-30 15:03:05.456466 Client::processMessage - got request with 4 tokens
2018-09-30 15:03:05.456497 Client::processMessage - request id 4b8c4db0-ec15-431f-8b40-69d5d08a8bf1, request type: sip transaction id: c3ff6d0b-bec1-47c7-8013-066b1a6cdf1b, dialog id: 
2018-09-30 15:03:05.456527 ClientController::addApiRequest: clientMsgId 4b8c4db0-ec15-431f-8b40-69d5d08a8bf1; size: 3
2018-09-30 15:03:06.581229 tport.c:1002 tport_base_connect() tport_base_connect(0x100c28290): what(pf=2 ws/[127.0.0.1]:52432): Socket is not connected
2018-09-30 15:03:06.581292 tport.c:3412 tport_tsend() tport_socket failed in tsend
2018-09-30 15:03:06.581318 nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Socket is not connected
2018-09-30 15:03:06.581345 nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Socket is not connected) while sending 200 OK for INVITE (2734)
2018-09-30 15:03:06.581448 ClientController::addDialogForTransaction - added dialog (uas), now tracking: 2 dialogs and 3 net transactions
2018-09-30 15:03:06.581490 ClientController::addDialogForTransaction - transaction id 8f8ed0fb-28bf-4152-a8d9-1358165ed4ce has associated dialog avgpue8dt4eqv32nmmce;uas
2018-09-30 15:03:06.581525 timerG: Adding entry to go off in 500ms
2018-09-30 15:03:06.581552 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:06.581580 timerH: Adding entry to go off in 32000ms
2018-09-30 15:03:06.581604 timerH: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:06.581645 ClientController::removeApiRequest: clientMsgId efa96e28-752b-4aa2-bef8-979c496bdc9d; size: 2
2018-09-30 15:03:06.581703 SipDialogController::doRespondToSipRequest thread 0x7fffd0b1e3c0
2018-09-30 15:03:06.581733 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - searching transactionId fc7c1ae1-3b30-40b3-b59d-3ed9034feb14
2018-09-30 15:03:06.581757 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - failed to find transactionId fc7c1ae1-3b30-40b3-b59d-3ed9034feb14, most likely this is a response to an invite we sent
2018-09-30 15:03:06.581787 pending-request: removing entry, prior to removal length: 2
2018-09-30 15:03:06.581812 pending-request: removed entry, setting timer for 62872ms after removal, length: 1
2018-09-30 15:03:06.581796 Client::write_handler - wrote 484 bytes: system:0
2018-09-30 15:03:06.581850 SipDialogController::addIncomingRequestTransaction - adding transactionId fc7c1ae1-3b30-40b3-b59d-3ed9034feb14 for irq:0x100e02170
2018-09-30 15:03:06.581895 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - searching transactionId fc7c1ae1-3b30-40b3-b59d-3ed9034feb14
2018-09-30 15:03:06.581922 SipDialogController::doRespondToSipRequest found incoming transaction 0x100e02170
2018-09-30 15:03:06.581951 SipTransport::getContactUri - created Contact header: sip:127.0.0.1:80
2018-09-30 15:03:06.582040 makeTags - Adding well-known header 'Call-ID' with value 'pfsi4s0nt7ilgdb8daem5r'
2018-09-30 15:03:06.582077 makeTags - Adding well-known header 'cseq' with value '9778 REGISTER'
2018-09-30 15:03:06.582106 makeTags - Adding well-known header 'from' with value '<sip:[email protected]>;tag=6m3scs6b6v'
2018-09-30 15:03:06.582135 makeTags - Adding well-known header 'to' with value '<sip:[email protected]>'
2018-09-30 15:03:06.582168 makeTags - Adding well-known header 'contact' with value '<sip:[email protected];transport=ws>;reg-id=1;+sip.instance="<urn:uuid:73e9a2b7-5d6a-4db4-8e72-ae91147914cd>";expires=0'
2018-09-30 15:03:06.582216 tport.c:3285 tport_tsend() tport_tsend(0x103042000) tpn = WS/127.0.0.1:52429
2018-09-30 15:03:06.582260 tport.c:4085 tport_resolve() tport_resolve addrinfo = 127.0.0.1:52429
2018-09-30 15:03:06.582303 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x1030c6000
2018-09-30 15:03:06.585235 Client::read_handler - bouncing client due to error reading: asio.misc:2
2018-09-30 15:03:06.585314 ClientController::leave - Removed client, count of connected clients is now: 0
2018-09-30 15:03:06.585341 Client::~Client
2018-09-30 15:03:07.763195 tport.c:1002 tport_base_connect() tport_base_connect(0x100c28290): what(pf=2 ws/[127.0.0.1]:52429): Socket is not connected
2018-09-30 15:03:07.763263 tport.c:3412 tport_tsend() tport_socket failed in tsend
2018-09-30 15:03:07.763298 nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Socket is not connected
2018-09-30 15:03:07.763325 nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Socket is not connected) while sending 200 OK for REGISTER (9778)
2018-09-30 15:03:07.763356 SipDialogController::doRespondToSipRequest destroying irq 0x100e02170
2018-09-30 15:03:07.763394 ClientController::removeApiRequest: clientMsgId af81efaf-0e6e-419b-ab36-412798b0e05c; size: 1
2018-09-30 15:03:07.763422 ClientController::route_api_response - client that has sent the request has disconnected: af81efaf-0e6e-419b-ab36-412798b0e05c
2018-09-30 15:03:07.763449 ClientController::removeNetTransaction: transactionId fc7c1ae1-3b30-40b3-b59d-3ed9034feb14; size: 2
2018-09-30 15:03:07.763487 tport.c:3285 tport_tsend() tport_tsend(0x103042000) tpn = WS/127.0.0.1:52429
2018-09-30 15:03:07.763524 tport.c:4085 tport_resolve() tport_resolve addrinfo = 127.0.0.1:52429
2018-09-30 15:03:07.763572 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x1030c6000
2018-09-30 15:03:08.908549 tport.c:1002 tport_base_connect() tport_base_connect(0x100c28290): what(pf=2 ws/[127.0.0.1]:52429): Socket is not connected
2018-09-30 15:03:08.908615 tport.c:3412 tport_tsend() tport_socket failed in tsend
2018-09-30 15:03:08.908640 nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Socket is not connected
2018-09-30 15:03:08.908675 nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Socket is not connected) while sending 500 Internal Server Error for REGISTER (9778)
2018-09-30 15:03:08.908712 SipDialogController::doRespondToSipRequest thread 0x7fffd0b1e3c0
2018-09-30 15:03:08.908758 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - searching transactionId c3ff6d0b-bec1-47c7-8013-066b1a6cdf1b
2018-09-30 15:03:08.908783 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - failed to find transactionId c3ff6d0b-bec1-47c7-8013-066b1a6cdf1b, most likely this is a response to an invite we sent
2018-09-30 15:03:08.908816 pending-request: removing entry, prior to removal length: 1
2018-09-30 15:03:08.908860 pending-request: removed entry, timer not set (queue is empty after removal), length: 0
2018-09-30 15:03:08.908914 SipDialogController::addIncomingRequestTransaction - adding transactionId c3ff6d0b-bec1-47c7-8013-066b1a6cdf1b for irq:0x100d01140
2018-09-30 15:03:08.908965 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - searching transactionId c3ff6d0b-bec1-47c7-8013-066b1a6cdf1b
2018-09-30 15:03:08.909009 SipDialogController::doRespondToSipRequest found incoming transaction 0x100d01140
2018-09-30 15:03:08.909036 SipTransport::getContactUri - created Contact header: sip:127.0.0.1:80
2018-09-30 15:03:08.909151 makeTags - Adding well-known header 'Call-ID' with value 'lriabj2uc92o10iomkdsjp'
2018-09-30 15:03:08.909203 makeTags - Adding well-known header 'cseq' with value '8978 REGISTER'
2018-09-30 15:03:08.909245 makeTags - Adding well-known header 'from' with value '<sip:[email protected]>;tag=dd3sr2r041'
2018-09-30 15:03:08.909292 makeTags - Adding well-known header 'to' with value '<sip:[email protected]>'
2018-09-30 15:03:08.909326 makeTags - Adding well-known header 'contact' with value '<sip:[email protected];transport=ws>;reg-id=1;+sip.instance="<urn:uuid:e220459a-56e7-4d81-b322-0956d85a0ffe>";expires=0'
2018-09-30 15:03:08.909412 tport.c:3285 tport_tsend() tport_tsend(0x1030a5000) tpn = WS/127.0.0.1:52432
2018-09-30 15:03:08.909477 tport.c:4085 tport_resolve() tport_resolve addrinfo = 127.0.0.1:52432
2018-09-30 15:03:08.909531 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x1030c6000
2018-09-30 15:03:10.051274 tport.c:1002 tport_base_connect() tport_base_connect(0x100c28290): what(pf=2 ws/[127.0.0.1]:52432): Socket is not connected
2018-09-30 15:03:10.051330 tport.c:3412 tport_tsend() tport_socket failed in tsend
2018-09-30 15:03:10.051355 nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Socket is not connected
2018-09-30 15:03:10.051407 nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Socket is not connected) while sending 200 OK for REGISTER (8978)
2018-09-30 15:03:10.051460 SipDialogController::doRespondToSipRequest destroying irq 0x100d01140
2018-09-30 15:03:10.051584 ClientController::removeApiRequest: clientMsgId 4b8c4db0-ec15-431f-8b40-69d5d08a8bf1; size: 0
2018-09-30 15:03:10.051618 ClientController::route_api_response - client that has sent the request has disconnected: 4b8c4db0-ec15-431f-8b40-69d5d08a8bf1
2018-09-30 15:03:10.051644 ClientController::removeNetTransaction: transactionId c3ff6d0b-bec1-47c7-8013-066b1a6cdf1b; size: 1
2018-09-30 15:03:10.051704 tport.c:3285 tport_tsend() tport_tsend(0x1030a5000) tpn = WS/127.0.0.1:52432
2018-09-30 15:03:10.051767 tport.c:4085 tport_resolve() tport_resolve addrinfo = 127.0.0.1:52432
2018-09-30 15:03:10.051826 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x1030c6000
2018-09-30 15:03:11.189600 tport.c:1002 tport_base_connect() tport_base_connect(0x100c28290): what(pf=2 ws/[127.0.0.1]:52432): Socket is not connected
2018-09-30 15:03:11.189722 tport.c:3412 tport_tsend() tport_socket failed in tsend
2018-09-30 15:03:11.189751 nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Socket is not connected
2018-09-30 15:03:11.189777 nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Socket is not connected) while sending 500 Internal Server Error for REGISTER (8978)
2018-09-30 15:03:11.189812 timerG: running timer function
2018-09-30 15:03:11.189838 timerG: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:11.189864 SipDialogController::retransmitFinalResponse irq:0x100e04090
2018-09-30 15:03:11.189923 timerG: Adding entry to go off in 1000ms
2018-09-30 15:03:11.189990 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:12.191461 timerG: running timer function
2018-09-30 15:03:12.191590 timerG: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:12.191629 SipDialogController::retransmitFinalResponse irq:0x100e04090
2018-09-30 15:03:12.191662 timerG: Adding entry to go off in 2000ms
2018-09-30 15:03:12.191725 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:14.196929 timerG: running timer function
2018-09-30 15:03:14.197034 timerG: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:14.197067 SipDialogController::retransmitFinalResponse irq:0x100e04090
2018-09-30 15:03:14.197098 timerG: Adding entry to go off in 4000ms
2018-09-30 15:03:14.197127 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:15.615414 DrachtioController::processWatchdogTimer
2018-09-30 15:03:15.615503 size of hash table for server-side transactions                  31
2018-09-30 15:03:15.615539 size of hash table for client-side transactions                  31
2018-09-30 15:03:15.615565 size of hash table for dialogs                                   31
2018-09-30 15:03:15.615587 number of server-side transactions in the hash table             4
2018-09-30 15:03:15.615610 number of client-side transactions in the hash table             1
2018-09-30 15:03:15.615634 number of dialogs in the hash table                              2
2018-09-30 15:03:15.615657 number of sip messages received                                  35
2018-09-30 15:03:15.615698 number of sip messages sent                                      26
2018-09-30 15:03:15.615736 number of sip requests received                                  32
2018-09-30 15:03:15.615767 number of sip requests sent                                      1
2018-09-30 15:03:15.615787 number of bad sip messages received                              0
2018-09-30 15:03:15.615821 number of bad sip requests received                              0
2018-09-30 15:03:15.615857 number of bad sip requests dropped                               0
2018-09-30 15:03:15.615881 number of bad sip reponses dropped                               0
2018-09-30 15:03:15.615921 number of client transactions created                            2
2018-09-30 15:03:15.615961 number of server transactions created                            32
2018-09-30 15:03:15.616001 number of in-dialog server transactions created                  1
2018-09-30 15:03:15.616021 number of server transactions that have received ack             0
2018-09-30 15:03:15.616051 number of server transactions that have received cancel          0
2018-09-30 15:03:15.616083 number of requests that were processed stateless                 31
2018-09-30 15:03:15.616104 number of requests converted to transactions by message callback 0
2018-09-30 15:03:15.616134 number of responses without matching request                     0
2018-09-30 15:03:15.616164 number of successful responses missing INVITE client transaction 0
2018-09-30 15:03:15.616194 number of requests merged by UAS                                 0
2018-09-30 15:03:15.616225 number of SIP requests sent by stack                             1
2018-09-30 15:03:15.616246 number of SIP responses sent by stack                            25
2018-09-30 15:03:15.616267 number of SIP requests retransmitted by stack                    0
2018-09-30 15:03:15.616289 number of SIP responses retransmitted by stack                   0
2018-09-30 15:03:15.616329 number of retransmitted SIP requests received by stack           0
2018-09-30 15:03:15.616349 number of SIP client transactions that has timeout               0
2018-09-30 15:03:15.616379 number of SIP server transactions that has timeout               0
2018-09-30 15:03:15.616414 SipDialogController storage counts
2018-09-30 15:03:15.616436 ----------------------------------
2018-09-30 15:03:15.616464 m_mapIrq2IIP size:                                               1
2018-09-30 15:03:15.616496 m_mapOrq2IIP size:                                               0
2018-09-30 15:03:15.616516 m_mapTransactionId2IIP size:                                     1
2018-09-30 15:03:15.616538 m_mapLeg2Dialog size:                                            2
2018-09-30 15:03:15.616568 m_mapId2Dialog size:                                             2
2018-09-30 15:03:15.616599 m_mapOrq2RIP size:                                               0
2018-09-30 15:03:15.616633 general queue size:                                              0
2018-09-30 15:03:15.616666 timer A queue size:                                              0
2018-09-30 15:03:15.616688 timer B queue size:                                              0
2018-09-30 15:03:15.616718 timer C queue size:                                              0
2018-09-30 15:03:15.616750 timer D queue size:                                              0
2018-09-30 15:03:15.616791 timer E queue size:                                              0
2018-09-30 15:03:15.616821 timer F queue size:                                              0
2018-09-30 15:03:15.616859 timer G queue size:                                              0
2018-09-30 15:03:15.616898 timer K queue size:                                              0
2018-09-30 15:03:15.616939 ClientController storage counts
2018-09-30 15:03:15.616969 ----------------------------------
2018-09-30 15:03:15.617008 m_clients size:                                                  0
2018-09-30 15:03:15.617030 m_services size:                                                 0
2018-09-30 15:03:15.617071 m_request_types size:                                            2
2018-09-30 15:03:15.617100 m_map_of_request_type_offsets size:                              2
2018-09-30 15:03:15.617139 m_mapDialogs size:                                               2
2018-09-30 15:03:15.617179 m_mapNetTransactions size:                                       1
2018-09-30 15:03:15.617210 m_mapAppTransactions size:                                       0
2018-09-30 15:03:15.617232 m_mapApiRequests size:                                           0
2018-09-30 15:03:15.617253 m_mapDialogId2Appname size:                                      0
2018-09-30 15:03:15.617320 PendingRequestController storage counts
2018-09-30 15:03:15.617418 ----------------------------------
2018-09-30 15:03:15.617450 m_mapCallId2Invite size:                                         0
2018-09-30 15:03:15.617477 m_mapTxnId2Invite size:                                          0
2018-09-30 15:03:15.617622 SipProxyController storage counts
2018-09-30 15:03:15.617656 ----------------------------------
2018-09-30 15:03:15.617682 m_mapCallId2Proxy size:                                          0
2018-09-30 15:03:15.617707 m_mapNonce2Challenge size:                                       0
2018-09-30 15:03:15.617731 general queue size:                                              0
2018-09-30 15:03:15.617769 timer A queue size:                                              0
2018-09-30 15:03:15.617803 timer B queue size:                                              0
2018-09-30 15:03:15.617834 timer C queue size:                                              0
2018-09-30 15:03:15.617857 timer D queue size:                                              0
2018-09-30 15:03:15.617879 timer E queue size:                                              0
2018-09-30 15:03:15.617900 timer F queue size:                                              0
2018-09-30 15:03:15.617922 timer G queue size:                                              0
2018-09-30 15:03:15.617942 timer K queue size:                                              0
2018-09-30 15:03:15.617964 m_mapUri2InvalidData size:                                       9
2018-09-30 15:03:18.200107 timerG: running timer function
2018-09-30 15:03:18.200161 timerG: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:18.200190 SipDialogController::retransmitFinalResponse irq:0x100e04090
2018-09-30 15:03:18.200219 timerG: Adding entry to go off in 4000ms
2018-09-30 15:03:18.200263 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:22.200748 timerG: running timer function
2018-09-30 15:03:22.200805 timerG: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:22.200834 SipDialogController::retransmitFinalResponse irq:0x100e04090
2018-09-30 15:03:22.200897 timerG: Adding entry to go off in 4000ms
2018-09-30 15:03:22.200988 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:24.952226 tport.c:2777 tport_wakeup_pri() tport_wakeup_pri(0x100c28290): events IN
2018-09-30 15:03:24.952298 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x1030c6000
2018-09-30 15:03:24.952370 tport.c:2668 tport_accept() tport_accept(0x1030c6000): new connection from ws/127.0.0.1:52458
2018-09-30 15:03:24.955321 tport.c:2801 tport_wakeup() tport_wakeup(0x1030c6000): events IN
2018-09-30 15:03:24.955405 tport.c:2892 tport_recv_event() tport_recv_event(0x1030c6000)
2018-09-30 15:03:24.955447 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x1030c6000) msg 0x100c2d7e0 from (ws/127.0.0.1:52458) has 519 bytes, veclen = 1
2018-09-30 15:03:24.955586 recv 519 bytes from ws/[127.0.0.1]:52458 at 15:03:24.955473:
REGISTER sip:ctel.com SIP/2.0
Via: SIP/2.0/WS k9rm0b3e3tqf.invalid;branch=z9hG4bK2514780
Max-Forwards: 70
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=1anatnponq
Call-ID: 640gpbu9ltlrote1jqto83
CSeq: 2722 REGISTER
Contact: <sip:[email protected];transport=ws>;reg-id=1;+sip.instance="<urn:uuid:d45ba787-9b52-4fcb-b7b5-fbfa94a58b2c>";expires=600
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: path, gruu, outbound
User-Agent: SIP.js/0.11.3
Content-Length: 0
 
2018-09-30 15:03:24.955622 tport.c:3051 tport_deliver() tport_deliver(0x1030c6000): msg 0x100c2d7e0 (519 bytes) from ws/127.0.0.1:52458 next=0x0
2018-09-30 15:03:24.955647 nta.c:2968 agent_recv_request() nta: received REGISTER sip:ctel.com SIP/2.0 (CSeq 2722)
2018-09-30 15:03:24.955707 nta.c:3263 agent_check_request_via() nta: Via check: received=127.0.0.1
2018-09-30 15:03:24.955751 nta.c:3183 agent_recv_request() nta: REGISTER (2722) to message callback
2018-09-30 15:03:24.955802 processMessageStatelessly - incoming message with call-id 640gpbu9ltlrote1jqto83 does not match an existing call leg, processed in thread 0x7fffd0b1e3c0
2018-09-30 15:03:24.955862 ClientController::selectClientForRequestOutsideDialog - there are 1 possible clients, we are starting with offset 0
2018-09-30 15:03:24.955897 ClientController::route_request_outside_dialog - Removing disconnected client while iterating
2018-09-30 15:03:24.955921 ClientController::route_request_outside_dialog - No clients found to handle incoming register request
2018-09-30 15:03:24.955945 processNewRequest - No providers available for REGISTER
2018-09-30 15:03:24.956025 tport.c:3285 tport_tsend() tport_tsend(0x1030c6000) tpn = WS/127.0.0.1:5060
2018-09-30 15:03:24.956069 tport_type_ws.c:311 tport_send_stream_ws() tport_ws_writevec: vec 0x1030c61f0 0x101807e00 284 (284)
2018-09-30 15:03:24.956112 tport.c:3531 tport_send_msg() tport_vsend returned 284
2018-09-30 15:03:24.956189 send 284 bytes to ws/[127.0.0.1]:52458 at 15:03:24.956064:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/WS k9rm0b3e3tqf.invalid;branch=z9hG4bK2514780;received=127.0.0.1;rport=52458
From: <sip:[email protected]>;tag=1anatnponq
To: <sip:[email protected]>;tag=BjHQH6K8ZQrSr
Call-ID: 640gpbu9ltlrote1jqto83
CSeq: 2722 REGISTER
Content-Length: 0
 
2018-09-30 15:03:24.956221 tport.c:2324 tport_set_secondary_timer() tport(0x1030c6000): reset timer
2018-09-30 15:03:24.956253 tport.c:2324 tport_set_secondary_timer() tport(0x1030c6000): reset timer
2018-09-30 15:03:26.206359 timerG: running timer function
2018-09-30 15:03:26.206473 timerG: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:26.206516 SipDialogController::retransmitFinalResponse irq:0x100e04090
2018-09-30 15:03:26.206558 timerG: Adding entry to go off in 4000ms
2018-09-30 15:03:26.206587 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:28.152257 tport.c:2777 tport_wakeup_pri() tport_wakeup_pri(0x100c28290): events IN
2018-09-30 15:03:28.152335 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x1030e7000
2018-09-30 15:03:28.152487 tport.c:2668 tport_accept() tport_accept(0x1030e7000): new connection from ws/127.0.0.1:52459
2018-09-30 15:03:28.154515 tport.c:2801 tport_wakeup() tport_wakeup(0x1030e7000): events IN
2018-09-30 15:03:28.154597 tport.c:2892 tport_recv_event() tport_recv_event(0x1030e7000)
2018-09-30 15:03:28.154639 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x1030e7000) msg 0x100e066c0 from (ws/127.0.0.1:52459) has 519 bytes, veclen = 1
2018-09-30 15:03:28.154790 recv 519 bytes from ws/[127.0.0.1]:52459 at 15:03:28.154665:
REGISTER sip:ctel.com SIP/2.0
Via: SIP/2.0/WS bhlqp37rigq6.invalid;branch=z9hG4bK5744536
Max-Forwards: 70
To: <sip:[email protected]>
From: <sip:[email protected]>;tag=gadk6imq7n
Call-ID: p2u6ov5lt3qmrt7o217rsf
CSeq: 3057 REGISTER
Contact: <sip:[email protected];transport=ws>;reg-id=1;+sip.instance="<urn:uuid:d003b123-c30e-4d96-9087-04bdd323b112>";expires=600
Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER
Supported: path, gruu, outbound
User-Agent: SIP.js/0.11.3
Content-Length: 0
 
2018-09-30 15:03:28.154836 tport.c:3051 tport_deliver() tport_deliver(0x1030e7000): msg 0x100e066c0 (519 bytes) from ws/127.0.0.1:52459 next=0x0
2018-09-30 15:03:28.154866 nta.c:2968 agent_recv_request() nta: received REGISTER sip:ctel.com SIP/2.0 (CSeq 3057)
2018-09-30 15:03:28.154894 nta.c:3263 agent_check_request_via() nta: Via check: received=127.0.0.1
2018-09-30 15:03:28.154923 nta.c:3183 agent_recv_request() nta: REGISTER (3057) to message callback
2018-09-30 15:03:28.154947 processMessageStatelessly - incoming message with call-id p2u6ov5lt3qmrt7o217rsf does not match an existing call leg, processed in thread 0x7fffd0b1e3c0
2018-09-30 15:03:28.154990 No connected clients found to handle incoming register request
2018-09-30 15:03:28.155014 processNewRequest - No providers available for REGISTER
2018-09-30 15:03:28.155094 tport.c:3285 tport_tsend() tport_tsend(0x1030e7000) tpn = WS/127.0.0.1:5060
2018-09-30 15:03:28.155133 tport_type_ws.c:311 tport_send_stream_ws() tport_ws_writevec: vec 0x1030e71f0 0x101030600 284 (284)
2018-09-30 15:03:28.155177 tport.c:3531 tport_send_msg() tport_vsend returned 284
2018-09-30 15:03:28.155278 send 284 bytes to ws/[127.0.0.1]:52459 at 15:03:28.155129:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/WS bhlqp37rigq6.invalid;branch=z9hG4bK5744536;received=127.0.0.1;rport=52459
From: <sip:[email protected]>;tag=gadk6imq7n
To: <sip:[email protected]>;tag=cUagK14BX0ecm
Call-ID: p2u6ov5lt3qmrt7o217rsf
CSeq: 3057 REGISTER
Content-Length: 0
 
2018-09-30 15:03:28.155317 tport.c:2324 tport_set_secondary_timer() tport(0x1030e7000): reset timer
2018-09-30 15:03:28.155352 tport.c:2324 tport_set_secondary_timer() tport(0x1030e7000): reset timer
2018-09-30 15:03:28.748648 nta.c:7135 _nta_incoming_timer() nta: sending final response failed, timeout 180 response
2018-09-30 15:03:28.748725 SipDialogController::processCancel with null sip pointer; irq 0x100e04090, most probably timerH indicating end of final response retransmissions
2018-09-30 15:03:28.748764 SipDialogController::processCancelOrAck - clearing IIP for leg 0x100e04490
2018-09-30 15:03:28.748799 SipDialogController::clearIIPFinal:  clearing leg 0x100e04490
2018-09-30 15:03:28.748849 tport.c:3285 tport_tsend() tport_tsend(0x1030a5000) tpn = WS/127.0.0.1:52432
2018-09-30 15:03:28.748889 tport.c:4085 tport_resolve() tport_resolve addrinfo = 127.0.0.1:52432
2018-09-30 15:03:28.748964 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x103108000
2018-09-30 15:03:29.940934 tport.c:1002 tport_base_connect() tport_base_connect(0x100c28290): what(pf=2 ws/[127.0.0.1]:52432): Socket is not connected
2018-09-30 15:03:29.941003 tport.c:3412 tport_tsend() tport_socket failed in tsend
2018-09-30 15:03:29.941040 nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Socket is not connected
2018-09-30 15:03:29.941069 nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Socket is not connected) while sending 500 Internal Server Error for INVITE (2734)
2018-09-30 15:03:29.941099 nta.c:7135 _nta_incoming_timer() nta: sending final response failed, timeout 0 response
2018-09-30 15:03:29.941137 tport.c:3285 tport_tsend() tport_tsend(0x103042000) tpn = WS/127.0.0.1:52429
2018-09-30 15:03:29.941175 tport.c:4085 tport_resolve() tport_resolve addrinfo = 127.0.0.1:52429
2018-09-30 15:03:29.941223 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x103108000
2018-09-30 15:03:31.141535 tport.c:1002 tport_base_connect() tport_base_connect(0x100c28290): what(pf=2 ws/[127.0.0.1]:52429): Socket is not connected
2018-09-30 15:03:31.141602 tport.c:3412 tport_tsend() tport_socket failed in tsend
2018-09-30 15:03:31.141641 nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Socket is not connected
2018-09-30 15:03:31.141669 nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Socket is not connected) while sending 500 Internal Server Error for REGISTER (9778)
2018-09-30 15:03:31.141699 nta.c:7135 _nta_incoming_timer() nta: sending final response failed, timeout 0 response
2018-09-30 15:03:31.141737 tport.c:3285 tport_tsend() tport_tsend(0x1030a5000) tpn = WS/127.0.0.1:52432
2018-09-30 15:03:31.141775 tport.c:4085 tport_resolve() tport_resolve addrinfo = 127.0.0.1:52432
2018-09-30 15:03:31.141823 tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x100c28290): new secondary tport 0x103108000
2018-09-30 15:03:32.325120 tport.c:1002 tport_base_connect() tport_base_connect(0x100c28290): what(pf=2 ws/[127.0.0.1]:52432): Socket is not connected
2018-09-30 15:03:32.325187 tport.c:3412 tport_tsend() tport_socket failed in tsend
2018-09-30 15:03:32.325221 nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Socket is not connected
2018-09-30 15:03:32.325248 nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Socket is not connected) while sending 500 Internal Server Error for REGISTER (8978)
2018-09-30 15:03:32.325278 nta.c:7192 _nta_incoming_timer() nta: timer H fired, timeout and terminate 401 response
2018-09-30 15:03:32.325305 nta.c:5913 incoming_reclaim_queued() incoming_reclaim_all(0x0, 0x0, 0x7fff5fbfbbb0)
2018-09-30 15:03:32.325361 nta.c:7275 _nta_incoming_timer() nta_incoming_timer: 0/1 resent, 1/1 tout, 1/0 term, 4/4 free
2018-09-30 15:03:32.325389 nta.c:1298 agent_timer() nta: timer set next to 8705 ms
2018-09-30 15:03:33.783790 timerG: running timer function
2018-09-30 15:03:33.783849 timerG: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:33.783880 SipDialogController::retransmitFinalResponse irq:0x100e04090
2018-09-30 15:03:33.783912 timerG: Adding entry to go off in 4000ms
2018-09-30 15:03:33.783939 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:37.459070 nta.c:9083 outgoing_timer_bf() nta: timer F fired, terminating ACK (128836424)
2018-09-30 15:03:37.459173 nta.c:9030 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 1/1 tout, 0/0 term, 0/1 free
2018-09-30 15:03:37.459215 nta.c:1291 agent_timer() nta: timer not set
2018-09-30 15:03:37.783922 timerG: running timer function
2018-09-30 15:03:37.783983 timerG: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:37.784015 SipDialogController::retransmitFinalResponse irq:0x100e04090
2018-09-30 15:03:37.784046 timerG: Adding entry to go off in 4000ms
2018-09-30 15:03:37.784074 timerG: Adding entry to the head (queue was empty), length: 1
2018-09-30 15:03:38.583437 timerH: running timer function
2018-09-30 15:03:38.583542 timerH: timer not set (queue is empty after processing expired timers), length: 0
2018-09-30 15:03:38.583576 SipDialogController::endRetransmitFinalResponse - never received ACK for final response to incoming INVITE; irq:0x100e04090 source address was 127.0.0.1
2018-09-30 15:03:38.583604 timerG: removing entry, prior to removal length: 1
2018-09-30 15:03:38.583629 timerG: removed entry, timer not set (queue is empty after removal), length: 0
Process 9728 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
    frame #0: 0x00000001001d6448 drachtio`boost::shared_ptr<drachtio::IIP>::shared_ptr(boost::shared_ptr<drachtio::IIP> const&) + 24
drachtio`boost::shared_ptr<drachtio::IIP>::shared_ptr:
->  0x1001d6448 <+24>: movq   (%rdi), %rdi
    0x1001d644b <+27>: movq   %rdi, (%rsi)
    0x1001d644e <+30>: addq   $0x8, %rsi
    0x1001d6452 <+34>: movq   -0x10(%rbp), %rdi
Target 1: (drachtio) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
  * frame #0: 0x00000001001d6448 drachtio`boost::shared_ptr<drachtio::IIP>::shared_ptr(boost::shared_ptr<drachtio::IIP> const&) + 24
    frame #1: 0x00000001001c0c1d drachtio`boost::shared_ptr<drachtio::IIP>::shared_ptr(boost::shared_ptr<drachtio::IIP> const&) + 29
    frame #2: 0x0000000100199198 drachtio`drachtio::SipDialogController::clearIIP(nta_leg_s*) + 168
    frame #3: 0x00000001001b615a drachtio`drachtio::SipDialogController::endRetransmitFinalResponse(nta_incoming_s*, tport_s*, boost::shared_ptr<drachtio::SipDialog>) + 794
    frame #4: 0x00000001001d1ea3 drachtio`boost::_mfi::mf3<void, drachtio::SipDialogController, nta_incoming_s*, tport_s*, boost::shared_ptr<drachtio::SipDialog> >::operator()(drachtio::SipDialogController*, nta_incoming_s*, tport_s*, boost::shared_ptr<drachtio::SipDialog>) const + 179
    frame #5: 0x00000001001d1d9d drachtio`void boost::_bi::list4<boost::_bi::value<drachtio::SipDialogController*>, boost::_bi::value<nta_incoming_s*>, boost::_bi::value<tport_s*>, boost::_bi::value<boost::shared_ptr<drachtio::SipDialog> > >::operator()<boost::_mfi::mf3<void, drachtio::SipDialogController, nta_incoming_s*, tport_s*, boost::shared_ptr<drachtio::SipDialog> >, boost::_bi::rrlist1<void*> >(boost::_bi::type<void>, boost::_mfi::mf3<void, drachtio::SipDialogController, nta_incoming_s*, tport_s*, boost::shared_ptr<drachtio::SipDialog> >&, boost::_bi::rrlist1<void*>&, int) + 189
    frame #6: 0x00000001001d1cbd drachtio`void boost::_bi::bind_t<void, boost::_mfi::mf3<void, drachtio::SipDialogController, nta_incoming_s*, tport_s*, boost::shared_ptr<drachtio::SipDialog> >, boost::_bi::list4<boost::_bi::value<drachtio::SipDialogController*>, boost::_bi::value<nta_incoming_s*>, boost::_bi::value<tport_s*>, boost::_bi::value<boost::shared_ptr<drachtio::SipDialog> > > >::operator()<void*>(void*&&) + 77
    frame #7: 0x00000001001d19db drachtio`boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf3<void, drachtio::SipDialogController, nta_incoming_s*, tport_s*, boost::shared_ptr<drachtio::SipDialog> >, boost::_bi::list4<boost::_bi::value<drachtio::SipDialogController*>, boost::_bi::value<nta_incoming_s*>, boost::_bi::value<tport_s*>, boost::_bi::value<boost::shared_ptr<drachtio::SipDialog> > > >, void, void*>::invoke(boost::detail::function::function_buffer&, void*) + 59
    frame #8: 0x000000010021bda5 drachtio`boost::function1<void, void*>::operator()(void*) const + 149
    frame #9: 0x000000010021bc93 drachtio`drachtio::TimerQueue::doTimer(su_timer_s*) + 2083
    frame #10: 0x000000010021aca9 drachtio`(anonymous namespace)::timer_function(void*, su_timer_s*, void*) + 41
    frame #11: 0x00000001002e83e7 drachtio`su_timer_expire + 983
    frame #12: 0x00000001002d1341 drachtio`su_base_port_run + 289
    frame #13: 0x00000001002dba51 drachtio`su_port_run + 49
    frame #14: 0x00000001002dba0f drachtio`su_root_run + 111
    frame #15: 0x0000000100028a9b drachtio`drachtio::DrachtioController::run() + 40091
    frame #16: 0x00000001000024f4 drachtio`main + 148
    frame #17: 0x00007fffc7c05235 libdyld.dylib`start + 1
    frame #18: 0x00007fffc7c05235 libdyld.dylib`start + 1

Error sending to remote host name when DNS query returns ipv6 address

Hello,

I'm relatively new to SIP protocol. I'm trying to use Kurento to make SIP calls following this tutorial : https://github.com/daimoc/Kurento-SIP-GW. It uses drachtio server to contact sotphones like linphone.

I managed to register using the account [email protected] and to call the account [email protected] (i e an account from a different provider) but when I try to contact [email protected] (i e an account from the same provider), I get the following mistake :
407 Proxy Authentication Required for INVITE

I tried to add authentication as in the following issue : drachtio/drachtio-srf#3 but with no luck. I think I may be missing something as I'm just beginning to work with drachtio in peculiar and SIP in general.

I attached the file containing the code related to drachtio and the logs. I just modified the password.

log.txt

sipstack.txt

Could you please help me identify the source of the error ?

Thank you,

Guillaume Prat

Make deployment in K8s easier

Some params are able to be set using command line flags but the new cluster ones cannot.

Is there an easier way to set certain params? Right now, using a k8s service url as a destination for call routing in clustering isn't the easiest of things in k8s

I'm not even 100% sure how to solve this with the current functionality available in k8s

Segment Violation

Hi Dave,

I´m testing drachtio-server under siprec enviroment with opensips. After few minutes running the drachtio-server crash with Segment Violation error. ¿How can I help you to resolve?

018-11-07 09:59:11.571880 tport.c:2324 tport_set_secondary_timer() tport(0x12a5f00): reset timer
2018-11-07 09:59:11.572008 timerG: Adding entry to go off in 4000ms
2018-11-07 09:59:11.572124 timerG: Adding entry to the tail of the queue: length 4
2018-11-07 09:59:11.785494 timerH: running timer function
2018-11-07 09:59:11.785587 timerH: Setting timer for 6149ms after processing expired timers, length: 3
2018-11-07 09:59:11.785625 SipDialogController::endRetransmitFinalResponse - never received ACK for final response to incoming INVITE; irq:0x12c3fe0 source address was 192.168.88.54
2018-11-07 09:59:11.785659 timerG: removing entry, prior to removal length: 4
2018-11-07 09:59:11.785698 SipDialogController::clearIIPFinal: clearing leg 0x12bd930
2018-11-07 09:59:11.785738 nta.c:5832 incoming_free() nta: incoming_free(0x12c3fe0)
Violación de segmento

Cancel event not recieved by SRF

We're having an issue where our API doesn't find out when an incoming SIP call is cancelled. We're using drachtio-server along with drachtio-srf.
Here is the flow;
FS - INVITE -> drachtio: dracthio-srf processes invite, triggers API.
FS <- 100 Trying - drachtio
FS - CANCEL -> drachtio: drachtio-srf doesn't receive anything (not in srf.cancel, in middleware, or in CDR)
FS <- 200 OK - drachtio (response to cancel)
FS <- 487 - drachtio (response to INVITE)
FS - ACK -> drachtio
FS <- 603 DECLINE - drachtio
FS - ACK -> drachtio

We need to terminate our calls on the API when we receive a cancel, but we can't get that to work without the cancel event triggering.

Here are the drachtio logs from a call where this happens:
`
2018-04-20 15:00:42.560577 tport.c:2777 tport_wakeup_pri() tport_wakeup_pri(0x1d767e0): events IN
2018-04-20 15:00:42.560669 tport.c:2892 tport_recv_event() tport_recv_event(0x1d767e0)
2018-04-20 15:00:42.560729 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x1d767e0) msg 0x1d7b0f0 from (udp/172.19.0.3:5060) has 1433 bytes, veclen = 1
2018-04-20 15:00:42.561070 recv 1433 bytes from udp/[172.19.0.19]:5160 at 15:00:42.560778:
INVITE sip:103@my-team SIP/2.0
Via: SIP/2.0/UDP 172.19.0.19:5160;rport;branch=z9hG4bK2Utt8y7Xcet6K
Route: sip:drachtio:5060
Max-Forwards: 68
From: "aea93eeef316177ec14b00aaa8f645c42" sip:[email protected];tag=FmNgr86jrB80N
To: sip:103@my-team
Call-ID: 6fff8b5c-bf4e-1236-e893-0242ac130013
CSeq: 121782157 INVITE
Contact: sip:[email protected]:5160
User-Agent: SK-1.2.3
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 280
X-Team: my-team
X-Server: 172.19.0.19
X-UUID: 8729276a-8741-408c-a528-4e474b62c7bb
X-Client: hardphone
X-Caller-PID: aea93eeef316177ec14b00aaa8f645c42
X-FS-Support: update_display,send_info
Remote-Party-ID: "aea93eeef316177ec14b00aaa8f645c42" sip:[email protected];party=calling;screen=yes;privacy=off

v=0
o=FreeSWITCH 1524217560 1524217561 IN IP4 172.19.0.19
s=FreeSWITCH
c=IN IP4 172.19.0.19
t=0 0
m=audio 18882 RTP/AVP 102
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=ptime:20
2018-04-20 15:00:42.561110 tport.c:3051 tport_deliver() tport_deliver(0x1d767e0): msg 0x1d7b0f0 (1433 bytes) from udp/172.19.0.19:5060 next=(nil)
2018-04-20 15:00:42.561137 nta.c:2968 agent_recv_request() nta: received INVITE sip:103@my-team SIP/2.0 (CSeq 121782157)
2018-04-20 15:00:42.561168 nta.c:3183 agent_recv_request() nta: INVITE (121782157) to message callback
2018-04-20 15:00:42.561190 processMessageStatelessly - incoming message with call-id 6fff8b5c-bf4e-1236-e893-0242ac130013 does not match an existing call leg, processed in thread 7f4a798b5780
2018-04-20 15:00:42.561250 tport.c:3285 tport_tsend() tport_tsend(0x1d767e0) tpn = UDP/172.19.0.19:5160
2018-04-20 15:00:42.561282 tport.c:4085 tport_resolve() tport_resolve addrinfo = 172.19.0.19:5160
2018-04-20 15:00:42.561305 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d767e0): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:42.561327 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d76c90): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:42.561348 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d77140): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:42.561411 tport.c:3531 tport_send_msg() tport_vsend returned 322
2018-04-20 15:00:42.561515 send 322 bytes to udp/[172.19.0.19]:5160 at 15:00:42.561379:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.19.0.19:5160;rport=5160;branch=z9hG4bK2Utt8y7Xcet6K
From: "aea93eeef316177ec14b00aaa8f645c42" sip:[email protected];tag=FmNgr86jrB80N
To: sip:103@my-team
Call-ID: 6fff8b5c-bf4e-1236-e893-0242ac130013
CSeq: 121782157 INVITE
Content-Length: 0

2018-04-20 15:00:42.561567 ClientController::route_request_outside_dialog - there are 1 possible clients, we are starting with offset 0
2018-04-20 15:00:42.561610 ClientController::route_request_outside_dialog - Selected client at offset 0
2018-04-20 15:00:42.563229 PendingRequestController::add - tport: 0x1d767e0, Call-ID: 6fff8b5c-bf4e-1236-e893-0242ac130013, transactionId ba8468e9-4343-4714-b5d3-c18e9a99cad4
2018-04-20 15:00:42.563316 pending-request: Adding entry to go off in 64000ms
2018-04-20 15:00:42.563354 pending-request: Adding entry to the head (queue was empty), length: 1
2018-04-20 15:00:42.563520 ClientController::addNetTransaction: transactionId ba8468e9-4343-4714-b5d3-c18e9a99cad4; size: 1
2018-04-20 15:00:42.563618 No connected clients found to handle incoming cdr:attempt request
2018-04-20 15:00:42.566345 Client::write_handler - wrote 1573 bytes: system:0
2018-04-20 15:00:50.020597 tport.c:2777 tport_wakeup_pri() tport_wakeup_pri(0x1d767e0): events IN
2018-04-20 15:00:50.020696 tport.c:2892 tport_recv_event() tport_recv_event(0x1d767e0)
2018-04-20 15:00:50.020746 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x1d767e0) msg 0x1d71530 from (udp/172.19.0.3:5060) has 423 bytes, veclen = 1
2018-04-20 15:00:50.020948 recv 423 bytes from udp/[172.19.0.19]:5160 at 15:00:50.020793:
CANCEL sip:103@my-team SIP/2.0
Via: SIP/2.0/UDP 172.19.0.19:5160;rport;branch=z9hG4bK2Utt8y7Xcet6K
Route: sip:drachtio:5060
Max-Forwards: 68
From: "aea93eeef316177ec14b00aaa8f645c42" sip:[email protected];tag=FmNgr86jrB80N
To: sip:103@my-team
Call-ID: 6fff8b5c-bf4e-1236-e893-0242ac130013
CSeq: 121782157 CANCEL
Reason: SIP;cause=487;text="ORIGINATOR_CANCEL"
Content-Length: 0

2018-04-20 15:00:50.021008 tport.c:3051 tport_deliver() tport_deliver(0x1d767e0): msg 0x1d71530 (423 bytes) from udp/172.19.0.19:5060 next=(nil)
2018-04-20 15:00:50.021050 nta.c:2968 agent_recv_request() nta: received CANCEL sip:103@my-team SIP/2.0 (CSeq 121782157)
2018-04-20 15:00:50.021099 nta.c:3183 agent_recv_request() nta: CANCEL (121782157) to message callback
2018-04-20 15:00:50.021134 processMessageStatelessly - incoming message with call-id 6fff8b5c-bf4e-1236-e893-0242ac130013 does not match an existing call leg, processed in thread 7f4a798b5780
2018-04-20 15:00:50.021193 received quick cancel for invite that is out to client for disposition: 6fff8b5c-bf4e-1236-e893-0242ac130013
2018-04-20 15:00:50.023305 Client::write_handler - wrote 561 bytes: system:0
2018-04-20 15:00:50.023401 tport.c:3285 tport_tsend() tport_tsend(0x1d767e0) tpn = UDP/172.19.0.19:5160
2018-04-20 15:00:50.024091 tport.c:4085 tport_resolve() tport_resolve addrinfo = 172.19.0.19:5160
2018-04-20 15:00:50.024147 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d767e0): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:50.024187 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d76c90): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:50.024224 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d77140): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:50.024342 tport.c:3531 tport_send_msg() tport_vsend returned 336
2018-04-20 15:00:50.024495 send 336 bytes to udp/[172.19.0.19]:5160 at 15:00:50.024272:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.19.0.19:5160;rport=5160;branch=z9hG4bK2Utt8y7Xcet6K
From: "aea93eeef316177ec14b00aaa8f645c42" sip:[email protected];tag=FmNgr86jrB80N
To: sip:103@my-team;tag=6yeS5m4r78ejD
Call-ID: 6fff8b5c-bf4e-1236-e893-0242ac130013
CSeq: 121782157 CANCEL
Content-Length: 0

2018-04-20 15:00:50.024607 tport.c:3285 tport_tsend() tport_tsend(0x1d767e0) tpn = UDP/172.19.0.19:5160
2018-04-20 15:00:50.024657 tport.c:4085 tport_resolve() tport_resolve addrinfo = 172.19.0.19:5160
2018-04-20 15:00:50.024697 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d767e0): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:50.024734 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d76c90): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:50.024771 tport.c:4770 tport_by_addrinfo() tport_by_addrinfo(0x1d77140): not found by name UDP/172.19.0.19:5160
2018-04-20 15:00:50.024842 tport.c:3531 tport_send_msg() tport_vsend returned 352
2018-04-20 15:00:50.024985 send 352 bytes to udp/[172.19.0.19]:5160 at 15:00:50.024812:
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 172.19.0.19:5160;rport=5160;branch=z9hG4bK2Utt8y7Xcet6K
From: "aea93eeef316177ec14b00aaa8f645c42" sip:[email protected];tag=FmNgr86jrB80N
To: sip:103@my-team;tag=777H7FNv4H54r
Call-ID: 6fff8b5c-bf4e-1236-e893-0242ac130013
CSeq: 121782157 INVITE
Content-Length: 0

2018-04-20 15:00:50.025366 tport.c:2777 tport_wakeup_pri() tport_wakeup_pri(0x1d767e0): events IN
2018-04-20 15:00:50.025421 tport.c:2892 tport_recv_event() tport_recv_event(0x1d767e0)
2018-04-20 15:00:50.025465 tport.c:3233 tport_recv_iovec() tport_recv_iovec(0x1d767e0) msg 0x1d7d880 from (udp/172.19.0.3:5060) has 387 bytes, veclen = 1
2018-04-20 15:00:50.025633 recv 387 bytes from udp/[172.19.0.19]:5160 at 15:00:50.025504:
ACK sip:103@my-team SIP/2.0
Via: SIP/2.0/UDP 172.19.0.19:5160;rport;branch=z9hG4bK2Utt8y7Xcet6K
Route: sip:drachtio:5060
Max-Forwards: 68
From: "aea93eeef316177ec14b00aaa8f645c42" sip:[email protected];tag=FmNgr86jrB80N
To: sip:103@my-team;tag=777H7FNv4H54r
Call-ID: 6fff8b5c-bf4e-1236-e893-0242ac130013
CSeq: 121782157 ACK
Content-Length: 0

2018-04-20 15:00:50.025687 tport.c:3051 tport_deliver() tport_deliver(0x1d767e0): msg 0x1d7d880 (387 bytes) from udp/172.19.0.19:5060 next=(nil)
2018-04-20 15:00:50.025727 nta.c:2968 agent_recv_request() nta: received ACK sip:103@my-team SIP/2.0 (CSeq 121782157)
2018-04-20 15:00:50.025774 nta.c:3183 agent_recv_request() nta: ACK (121782157) to message callback
2018-04-20 15:00:50.025809 processMessageStatelessly - incoming message with call-id 6fff8b5c-bf4e-1236-e893-0242ac130013 does not match an existing call leg, processed in thread 7f4a798b5780
`

segmentation fault (core dumped)

Not sure why i'm getting seg fault today. I havent touched drachtio in a while and updated the docker image. also updated native webrtc + sipjs to latest build. could be a combination of those or something.

9/19/2018 7:22:57 PM2018-09-20 02:22:57.933726 Client::processMessage - got request with 4 tokens
9/19/2018 7:22:57 PM2018-09-20 02:22:57.933784 Client::processMessage - request id 22b36e44-8bfe-40f9-a07c-da80f98d9be9, request type: sip transaction id: 057a7e4c-d0ef-4171-b823-30598e2eb15d, dialog id:
9/19/2018 7:22:57 PM2018-09-20 02:22:57.933843 ClientController::addApiRequest: clientMsgId 22b36e44-8bfe-40f9-a07c-da80f98d9be9; size: 1
9/19/2018 7:22:57 PM2018-09-20 02:22:57.933981 SipDialogController::doRespondToSipRequest thread 7f4f05db2780
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934057 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - searching transactionId 057a7e4c-d0ef-4171-b823-30598e2eb15d
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934109 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - failed to find transactionId 057a7e4c-d0ef-4171-b823-30598e2eb15d, most likely this is a response to an invite we sent
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934168 pending-request: removing entry, prior to removal length: 2
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934258 SipDialogController::addIncomingRequestTransaction - adding transactionId 057a7e4c-d0ef-4171-b823-30598e2eb15d for irq:0xa9edf0
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934320 SipDialogController::findAndRemoveTransactionIdForIncomingRequest - searching transactionId 057a7e4c-d0ef-4171-b823-30598e2eb15d
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934372 SipDialogController::doRespondToSipRequest found incoming transaction 0xa9edf0
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934427 SipTransport::getContactUri - created Contact header: sips:107.170.195.211:443
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934563 makeTags - Adding well-known header 'Call-ID' with value 'kfhiu15anf3jv4cf5dgl0i'
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934628 makeTags - Adding well-known header 'cseq' with value '8400 REGISTER'
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934688 makeTags - Adding well-known header 'from' with value '<sip:[email protected]>;tag=lav5nttr73'
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934748 makeTags - Adding well-known header 'to' with value '<sip:[email protected]>'
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934815 makeTags - Adding well-known header 'contact' with value '<sip:[email protected];transport=wss>;reg-id=1;+sip.instance="<urn:uuid:ead32da7-ffad-4f28-9741-ac82fb6b2cc0>";expires=600;expires=3600'
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934903 tport.c:3285 tport_tsend() tport_tsend(0x7f4f05d2d010) tpn = WSS/206.116.9.333:53833
9/19/2018 7:22:57 PM2018-09-20 02:22:57.934978 tport_type_ws.c:311 tport_send_stream_ws() tport_ws_writevec: vec 0x7f4f05d2d200 0xaaf7f0 462 (462)
9/19/2018 7:22:57 PM2018-09-20 02:22:57.935076 tport.c:3531 tport_send_msg() tport_vsend returned 462
9/19/2018 7:22:57 PM2018-09-20 02:22:57.935219 send 462 bytes to wss/[206.116.9.333]:53833 at 02:22:57.934971:
9/19/2018 7:22:57 PMSIP/2.0 200 OK
9/19/2018 7:22:57 PMVia: SIP/2.0/WSS 4g2o71dh3ft3.invalid;branch=z9hG4bK2628338;received=206.116.9.333;rport=53833
9/19/2018 7:22:57 PMFrom: <sip:[email protected]>;tag=lav5nttr73
9/19/2018 7:22:57 PMTo: <sip:[email protected]>;tag=KaUy95tv8pZFD
9/19/2018 7:22:57 PMCall-ID: kfhiu15anf3jv4cf5dgl0i
9/19/2018 7:22:57 PMCSeq: 8400 REGISTER
9/19/2018 7:22:57 PMContact: <sip:[email protected];transport=wss>;reg-id=1;+sip.instance="<urn:uuid:ead32da7-ffad-4f28-9741-ac82fb6b2cc0>";expires=600;expires=3600
9/19/2018 7:22:57 PMContent-Length: 0
9/19/2018 7:22:57 PM
9/19/2018 7:22:57 PM2018-09-20 02:22:57.935335 tport.c:2324 tport_set_secondary_timer() tport(0x7f4f05d2d010): reset timer
9/19/2018 7:22:57 PM2018-09-20 02:22:57.935401 nta.c:6879 incoming_reply() nta: sent 200 OK for REGISTER (8400)
9/19/2018 7:22:57 PM2018-09-20 02:22:57.935473 DrachtioController::cacheTportForSubscription added [email protected], expires: 3600, count is now: 2
9/19/2018 7:22:57 PM2018-09-20 02:22:57.935548 SipDialogController::doRespondToSipRequest destroying irq 0xa9edf0
9/19/2018 7:22:57 PM2018-09-20 02:22:57.935620 ClientController::removeApiRequest: clientMsgId 22b36e44-8bfe-40f9-a07c-da80f98d9be9; size: 0
9/19/2018 7:22:57 PM2018-09-20 02:22:57.935771 Client::write_handler - wrote 656 bytes: system:0
9/19/2018 7:22:57 PM2018-09-20 02:22:57.937577 ClientController::removeNetTransaction: transactionId 057a7e4c-d0ef-4171-b823-30598e2eb15d; size: 1
9/19/2018 7:22:57 PM2018-09-20 02:22:57.937669 nta.c:5832 incoming_free() nta: incoming_free(0xa9edf0)
9/19/2018 7:22:58 PM2018-09-20 02:22:58.033606 Client::read_handler read: 9a9734ff-766f-473a-9051-267058f27c7d|sip||
9/19/2018 7:22:58 PMINVITE sip:[email protected];transport=wss;transport=udp SIP/2.0
9/19/2018 7:22:58 PMDisplayname: kakawterraw
9/19/2018 7:22:58 PMToken: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpZCI6InU0NDc0NTk0MTE1NjIiLCJpYXQiOjE1MzM3ODAzOTJ9.G6k3RjpNizwAoKKs8w3EWgP_TCbMzL2mXPtZI-elnf8
9/19/2018 7:22:58 PMIcon: TEST
9/19/2018 7:22:58 PMId: u447459411562
9/19/2018 7:22:58 PMfrom: sip:u447459411562@localhost
9/19/2018 7:22:58 PMcontact: sip:u447459411562@localhost
9/19/2018 7:22:58 PMContent-Length: 3655
9/19/2018 7:22:58 PM
9/19/2018 7:22:58 PMv=0
9/19/2018 7:22:58 PMo=- 3936354754253720449 2 IN IP4 127.0.0.1
9/19/2018 7:22:58 PMs=-
9/19/2018 7:22:58 PMt=0 0
9/19/2018 7:22:58 PMa=group:BUNDLE audio
9/19/2018 7:22:58 PMa=msid-semantic: WMS TrTpwiGCnWfegxGrQg7OyPdG9bdboQ676LMK
9/19/2018 7:22:58 PMm=audio 31701 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
9/19/2018 7:22:58 PMc=IN IP4 107.170.195.211
9/19/2018 7:22:58 PMa=rtcp:28667 IN IP4 107.170.195.211
9/19/2018 7:22:58 PMa=candidate:2608504202 1 udp 2122260223 169.254.254.144 55700 typ host generation 0 network-id 2
9/19/2018 7:22:58 PMa=candidate:4211017816 1 udp 2122194687 175.25.50.127 55845 typ host generation 0 network-id 3
9/19/2018 7:22:58 PMa=candidate:545802801 1 udp 2122129151 175.25.50.110 65002 typ host generation 0 network-id 1 network-cost 10
9/19/2018 7:22:58 PMa=candidate:2608504202 2 udp 2122260222 169.254.254.144 49342 typ host generation 0 network-id 2
9/19/2018 7:22:58 PMa=candidate:4211017816 2 udp 2122194686 175.25.50.127 60325 typ host generation 0 network-id 3
9/19/2018 7:22:58 PMa=candidate:545802801 2 udp 2122129150 175.25.50.110 53308 typ host generation 0 network-id 1 network-cost 10
9/19/2018 7:22:58 PMa=candidate:2075594476 1 udp 1685987071 206.116.9.333 55845 typ srflx raddr 175.25.50.127 rport 55845 generation 0 network-id 3
9/19/2018 7:22:58 PMa=candidate:2075594476 2 udp 1685987070 206.116.9.333 60325 typ srflx raddr 175.25.50.127 rport 60325 generation 0 network-id 3
9/19/2018 7:22:58 PMa=candidate:2713734277 1 udp 1685921535 206.116.9.333 65002 typ srflx raddr 175.25.50.110 rport 65002 generation 0 network-id 1 network-cost 10
9/19/2018 7:22:58 PMa=candidate:2713734277 2 udp 1685921534 206.116.9.333 53308 typ srflx raddr 175.25.50.110 rport 53308 generation 0 network-id 1 network-cost 10
9/19/2018 7:22:58 PMa=candidate:3589890426 1 tcp 1518280447 169.254.254.144 9 typ host tcptype active generation 0 network-id 2
9/19/2018 7:22:58 PMa=candidate:3028087976 1 tcp 1518214911 175.25.50.127 9 typ host tcptype active generation 0 network-id 3
9/19/2018 7:22:58 PMa=candidate:1846261441 1 tcp 1518149375 175.25.50.110 9 typ host tcptype active generation 0 network-id 1 network-cost 10
9/19/2018 7:22:58 PMa=candidate:3589890426 2 tcp 1518280446 169.254.254.144 9 typ host tcptype active generation 0 network-id 2
9/19/2018 7:22:58 PMa=candidate:3028087976 2 tcp 1518214910 175.25.50.127 9 typ host tcptype active generation 0 network-id 3
9/19/2018 7:22:58 PMa=candidate:1846261441 2 tcp 1518149374 175.25.50.110 9 typ host tcptype active generation 0 network-id 1 network-cost 10
9/19/2018 7:22:58 PMa=candidate:231900439 1 udp 41819903 107.170.195.211 31701 typ relay raddr 206.116.9.333 rport 55845 generation 0 network-id 3
9/19/2018 7:22:58 PMa=candidate:231900439 2 udp 41819902 107.170.195.211 28667 typ relay raddr 206.116.9.333 rport 60325 generation 0 network-id 3
9/19/2018 7:22:58 PMa=candidate:231900439 1 udp 41754367 107.170.195.211 57208 typ relay raddr 206.116.9.333 rport 65002 generation 0 network-id 1 network-cost 10
9/19/2018 7:22:58 PMa=candidate:231900439 2 udp 41754366 107.170.195.211 22634 typ relay raddr 206.116.9.333 rport 53308 generation 0 network-id 1 network-cost 10
9/19/2018 7:22:58 PMa=ice-ufrag:n/HS
9/19/2018 7:22:58 PMa=ice-pwd:6Cvxz/vCIAQvNut8UUjIo5NQ
9/19/2018 7:22:58 PMa=ice-options:trickle
9/19/2018 7:22:58 PMa=fingerprint:sha-256 4F:E2:B7:AA:79:E2:1B:48:3B:8E:2B:4F:74:4A:A7:DC:61:80:7A:F5:F8:DA:48:B9:78:62:AE:09:FA:F3:DA:DF
9/19/2018 7:22:58 PMa=setup:actpass
9/19/2018 7:22:58 PMa=mid:audio
9/19/2018 7:22:58 PMa=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
9/19/2018 7:22:58 PMa=sendrecv
9/19/2018 7:22:58 PMa=rtcp-mux
9/19/2018 7:22:58 PMa=rtpmap:111 opus/48000/2
9/19/2018 7:22:58 PMa=rtcp-fb:111 transport-cc
9/19/2018 7:22:58 PMa=fmtp:111 minptime=10;useinbandfec=1
9/19/2018 7:22:58 PMa=rtpmap:103 ISAC/16000
9/19/2018 7:22:58 PMa=rtpmap:104 ISAC/32000
9/19/2018 7:22:58 PMa=rtpmap:9 G722/8000
9/19/2018 7:22:58 PMa=rtpmap:0 PCMU/8000
9/19/2018 7:22:58 PMa=rtpmap:8 PCMA/8000
9/19/2018 7:22:58 PMa=rtpmap:106 CN/32000
9/19/2018 7:22:58 PMa=rtpmap:105 CN/16000
9/19/2018 7:22:58 PMa=rtpmap:13 CN/8000
9/19/2018 7:22:58 PMa=rtpmap:110 telephone-event/48000
9/19/2018 7:22:58 PMa=rtpmap:112 telephone-event/32000
9/19/2018 7:22:58 PMa=rtpmap:113 telephone-event/16000
9/19/2018 7:22:58 PMa=rtpmap:126 telephone-event/8000
9/19/2018 7:22:58 PMa=ssrc:3438817673 cname:Bu7V21wm3Y6lfFBB
9/19/2018 7:22:58 PMa=ssrc:3438817673 msid:TrTpwiGCnWfegxGrQg7OyPdG9bdboQ676LMK e93b184e-6079-4280-8c16-25d86bbc9715
9/19/2018 7:22:58 PMa=ssrc:3438817673 mslabel:TrTpwiGCnWfegxGrQg7OyPdG9bdboQ676LMK
9/19/2018 7:22:58 PMa=ssrc:3438817673 label:e93b184e-6079-4280-8c16-25d86bbc9715
9/19/2018 7:22:58 PM
9/19/2018 7:22:58 PM
9/19/2018 7:22:58 PM2018-09-20 02:22:58.034254 Client::processMessage - got request with 4 tokens
9/19/2018 7:22:58 PM2018-09-20 02:22:58.034337 Client::processMessage - request id 9a9734ff-766f-473a-9051-267058f27c7d, request type: sip transaction id: , dialog id:
9/19/2018 7:22:58 PM2018-09-20 02:22:58.034485 Client::processMessage - sending a request outside of a dialog
9/19/2018 7:22:58 PM2018-09-20 02:22:58.034634 ClientController::addAppTransaction: transactionId 0ee5770a-ab34-4385-9e44-56d231930e00; size: 1
9/19/2018 7:22:58 PM2018-09-20 02:22:58.034719 ClientController::addApiRequest: clientMsgId 9a9734ff-766f-473a-9051-267058f27c7d; size: 1
9/19/2018 7:22:58 PM2018-09-20 02:22:58.034955 DrachtioController::findTportForSubscription: found transport for [email protected]
9/19/2018 7:22:58 PM2018-09-20 02:22:58.035045 SipProxyController::doSendRequestOutsideDialog selecting existing secondary transport 0x7f4f05d2d010
9/19/2018 7:22:58 PM2018-09-20 02:22:58.035125 SipDialogController::doSendRequestOutsideDialog - selected transport 0x7f4f05d2d010: wss/206.116.9.333:53833 for request-uri sip:[email protected];transport=wss;transport=udp
9/19/2018 7:22:58 PMSegmentation fault (core dumped)

Handling simultaneous SIP requests

Hi,

One issue I see from one of the clients we are testing is that after REGISTER, a SUBSCRIBE and PUBLISH are sent as separate transactions, but at relatively the same time. It appears as though drachtio-server (latest develop branch) seems to lose state. For example, it may respond properly tot he PUBLISH. In our code using drachtio-srf, we send a NOTIFY in response to the SUBSCRIBE (to reg events in this case). That NOTIFY ends up going out without a "To tag", with the wrong (a new?) "From tag", but with the correct Call-ID (of the SUBSCRIBE dialog).

It looks like in this case, SUBSCRIBE is received by drachtio, then a PUBLISH, PUBLISH is responded with 200 OK, then the SUBSCRIBE gets 200 OK, then the NOTIFY goes out with the incorrect information.

Sometimes it works, perhaps some minor timing changes cause different call flow. If we disable PUBLISH, it works fine as well. We are also looking to make the SUBSCRIBE/PUBLISH flow sequential, but, I am not sure if that is limited by standards for non-INVITE requests.

I am working on some logs and a packet capture to send to you.

Thanks

clear timerD on uac dialog when BYE received (before timerD fires)

scenario:

uac invite sent, answered received, ACK sent
BYE sent from either side before timerD (~32s) fires

result: spurious log message indicating that timerD was not cleared when dialog ended with BYE:

2017-09-18 01:53:03.903274 SipDialogController::timerD - wait timer for responses expired on leg , dialog id e57fa684-e084-4600-8b05-7d84066f05540x1a68620
2017-09-18 01:53:03.903284 SipDialogController::clearIIPFinal:  clearing leg 0x1a68620
2017-09-18 01:53:03.903298 nta.c:8813 outgoing_free() nta: outgoing_free(0x1aa7d80)
2017-09-18 01:53:03.903318 SipDialogController::clearDialog - unable to find dialog id e57fa684-e084-4600-8b05-7d84066f0554 probably because dialog failed (non-2XX), was cleared from far end (race condition), or 408 Request Timeout to BYE

(note: log messages occur when timerD fires, some time after BYE processed)

Drachtio exits immidiately on startup

I've compiled drachtio-server, and tried to run it. I know that it runs because it creates errors when it doesn't have a config file. However - the moment I correct the config file it just starts and exits. It doesn't send any output to the console.
Do you have an idea of how to solve this?

Heartbeat metrics - logfile/syslog alternative?

Hi Dave - have you considered providing an alternative method for data/metric extraction from Drachtio other than log/syslog/console? The current format of the 30 second heartbeat requires some pretty nasty log extracting and parsing, a storing of value counters (to obtain metrics that have increased since last heartbeat) and could be prone to errors based on the file entry formats.

What would be very useful is the ability to connect to the/an admin port and pull or subscribe to events on demand. The logic here is that one could connect to Drachtio, extract data and process accordingly in one single application rather than having to send data to log/syslog, filter, scan, parse and then have a process handle the scrubbed info.

The data in the heartbeat is fantastic! Would just love a simpler way to break it down.
Having the data dumped as a single json blob in a dedicated file would also be very nice to work with!

Many thanks

Gar

NAT handling

Up till now, I have done lots of testing with drachtio-server running in a Docker network along with my other services. External clients could come in and access the server, but it was all enclosed by a private network.

Now I am trying to deploy the Docker setup to AWS. However, when I run drachtio-server in a Docker network on an AWS EC2 instance, I can't getting NATing working correctly. The drachtio-server can't reach my clients. I even tries running drachtio-server directly on an AWS EC2 instance, but it has the same results. The log below is this case without Docker.

drachtio.txt

In this example, my client REGISTERs, sends a SUBSCRIBE, and sends a PUBLISH. We get the 200 OK responses back for both of those. However, the NOTIFY we send from the Node.js/srf side doesn't reach the client. This is after the fix from before where we now send the NOTIFY after the 200 OK is successfully sent (it works well in the private network scenario).

In the log, 5.5.5.5 is the public IP from my office and 10.11.33.* is the private IP range. 222.222.222.222 is the public IP of the AWS EC2 instance and 10.0.3.* is the private IP range there.

When I send the NOTIFY with the drachtio-srf object, I am using the received and rport parameters from the via[0] line (5.5.5.5:5070). But from the logs it looks like drachtio-server is trying to send to the private IP of my office network.

fatal error during git submodule

Hi,

During 'git submodule update --init --recursive'

I get: fatal: reference is not a tree: 3706ea6290216589...

Best

Building from source on Darwin/Mac

Instructions wasn't smooth sailing for me trying to build on a Mac (maybe its my computer but for anyone running into the same issue):

had to remove openssl that ships with the os by disabling System Integrity Protection and deleting the binary. remember to turn it back on.
installed openssl through brew
make sure /usr/local/Cellar/openssl only have one openssl incase of old install through brew. didnt build until i got only the latest (OpenSSL 1.0.2o 27 Mar 2018)
I installedbrew curl --with-openssl
i was using boost that got installed through brew but that didn't come with -lboost_thread has -lboost-thread_mt instead. Did the solution here https://discourse.brew.sh/t/could-not-link-to-boost/2125/4 but then craps out on re_detail_106300 (some regex method i think compatibility with the brew version)
uninstall boost from brew and used the one in deps
finally compiled the binary
ran into a bunch of these when trying to run the compiled drachtio binary

dyld: Library not loaded: libboost_log.dylib
  Referenced from: /usr/local/bin/drachtio
  Reason: image not found

from the deps/boost directory i symlink those dylib with find bin.v2/libs | grep .dylib | awk '{system("ln -s $PWD/" $1 " /usr/local/lib")}' assumig pwd is project/deps
then all good just need to create /etc/drachtio.conf.xml
have to run drachtio using sudo because of /var/log/drachtio permission
Yay working!!

Could have just run in docker but on the mac docker doesn't run natively, instead in a vm docker-machine (virtual box) with its own network subnet so the networking is behind another layer. used socat to proxy to the docker-machine it works but just incase best to run in host

👍

Mid call Mobility/ Wifi-Cell Network Handoff Consideration?

Hi Dave,

Could use your insights on this.

I can get network handoff to work with MICE and continuous ice gathering set. RTP automatically reflows to the other interface. Websocket connection reconnects automatically. I send register again to Drachtio. But after this point only the device that did the network handoff can send a bye.

Thanks!

Stateless Proxy Support

Would like to use multiple drachtio-servers to ship requests around. For example:

UE1         UE2       drachtioA       drachtioB
 |           |          |              |
 | INVITE (1)---------->|              |
 |           |          |(2)---------->|
 |           |          |              |
 |           |          |<----------(3)|
 |           |<------(4)|              |
 |           |          |              |

drachtioA handles most requests as a proxy and if coming from users from the internal network will forward the messages to another server, in this case, drachtioB. drachtioB acts as a Registrar/Proxy. In this case, UE1 and UE2 are registered with it. I want UE1 to send an INVITE to UE2 via drachtioA, then drachtioB, which will route the INVITE back through drachtioA to get to UE2. drachtioA would see the message coming from the external network and route to the internal client (UE2 address state would be in the application).

However, upon testing, I see the drachtio-server message "Discarding retransmitted request since we are a stateful proxy INVITE ...". Can drachtio-server be configured to be a stateless proxy? On a per message type request? Or is there a better way?

For drachtioA I am using drachtio Node.js app and for drachtioB I am using drachtio-srf.

Crash after Re-Invite

We have a drachtio server that we use to translate between custom signaling and SIP. We sometimes need to change media streams, and as a result we send a Re-Invite. When we do that, the server crashes after a short delay.

Here is the message we recieve when the server crashes:

2018-04-18 19:06:41.030436 nta.c:9073 outgoing_timer_bf() nta: timer F fired, terminating ACK (121703117)
2018-04-18 19:06:41.030636 nta.c:9020 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 1/2 tout, 0/1 term, 0/3 free
2018-04-18 19:06:41.030945 nta.c:1298 agent_timer() nta: timer set next to 242 ms
2018-04-18 19:06:41.273486 nta.c:9192 outgoing_timer_dk() nta: timer D fired, terminate INVITE (121703118)
2018-04-18 19:06:41.273613 nta.c:8890 outgoing_reclaim_queued() outgoing_reclaim_all((nil), (nil), 0x7ffc1ee6b910)
2018-04-18 19:06:41.273696 nta.c:9020 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 0/1 tout, 1/1 term, 1/3 free
2018-04-18 19:06:41.273780 nta.c:1298 agent_timer() nta: timer set next to 17 ms
2018-04-18 19:06:41.290968 nta.c:9073 outgoing_timer_bf() nta: timer F fired, terminating ACK (121703118)
2018-04-18 19:06:41.291072 nta.c:9020 _nta_outgoing_timer() nta_outgoing_timer: 0/0 resent, 1/1 tout, 0/0 term, 0/2 free
2018-04-18 19:06:41.291124 nta.c:1291 agent_timer() nta: timer not set
2018-04-18 19:06:41.529584 timerD: running timer function
2018-04-18 19:06:41.529712 timerD: timer not set (queue is empty after processing expired timers), length: 0
2018-04-18 19:06:41.529798 SipDialogController::timerD - wait timer for responses expired on leg , dialog id 30e60214-d9ad-429a-b5df-73fa7e05b7490x1325820
2018-04-18 19:06:41.529906 SipDialogController::clearIIPFinal: clearing leg 0x1325820

Drachtio-server's log shows an "error enabling tcp keepalive"

Hi Dave,

i'm trying to develop an IVR application in Node.js with Drachtio.
I've a problem with the drachtio-server (either master and dev branches) ;
when i run this testapp.js on a Ubuntu 14.04 server :

var app = require('drachtio')() ;
var Mrf = require('../') ;
var mrf = new Mrf(app) ;
var Srf = require('drachtio-srf') ;
var srf = new Srf(app) ;
var ms  ;

srf.connect({
  host: '127.0.0.1',
  port: 9022,
  secret: 'cymru',
}, function(hostport) {
  console.log('connected to server listening for SIP messages on ' + hostport) ;
}) ;

mrf.connect({
  address: '127.0.0.1',
  port: 8021,
  secret: 'ClueCon',
  listenPort: 8085
}, function(mediaServer) {
  ms = mediaServer;
  console.log('successfully connected to media server') ;
});

srf.invite( function(req, res) {
  
  // connect caller to an endpoint on the media server
  ms.connectCaller(req, res, function(err, ep, dialog) {
    if( err ) throw err ;

    // set up dialog handlers
    dialog.on('destroy', onCallerHangup.bind(dialog, ep)) ;

    // play some prompts
    ep.play(['ivr/8000/ivr-please_reenter_your_pin.wav',
      'ivr/8000/ivr-please_state_your_name_and_reason_for_calling.wav',
      'ivr/8000/ivr-you_lose.wav'], function(err, results){
        console.log('results: ', results) ;
      }) ;
  }) ; 
}) ;

function onCallerHangup( ep ) {
  // release endpoint
  ep.destroy() ;
}

The Drachtio-server's log shows an "error enabling tcp keepalive" :

0000003b|2017-May-01 21:59:35.937218| Received connection from client at 127.0.0.1:56774
0000003c|2017-May-01 21:59:35.937374| Client::Client - error enabling tcp keepalive
0000003d|2017-May-01 21:59:35.942937| Client::processAuthentication - validating secret cymru
0000003e|2017-May-01 21:59:35.943664| Client::processAuthentication - secret validated successfully: cymru

The testapp.js log shows an undefined port and the drachtio-srf doesn't seems to work correctly :

connected to server listening for SIP messages on undefined
successfully connected to media server

Can you help me ?
Do you think this problem is related with the c/c++ library ?

Thanks,
Massimo

Load balancing & high availability

How would you recommend load balancing the server for horizontal scaling and higher availability?

Also, can the drachtio-srf client connect to multiple servers if they are load balanced?

Thanks.

Files missing during `make` step

When running the make command the following get thrown:

Makefile.am: error: required file './AUTHORS' not found
Makefile.am: error: required file './ChangeLog' not found

I was able to solve it by manually creating the two files. They should really be part of the repo.

curl.h Dependency

In the cluster-experimental branch, there is a new dependency on libcurl (the build error is for curl.h). Is the recommend way, for Ubuntu 16.04, to have this dependency?

sudo apt install libcurl4-openssl-dev

For docker builds that reference cluster-experimental, I see the same issue, a library dependency is missing for curl.h reference.

Thanks.

Drachtio-Server doesn't send ACK to 200 OK Message

Hi, I am trying to use drachtio as a B2BUA with Rtpengine, everything works fine except 2 minor problems.

1, When trunk sends 200 OK with SDP, I think drachtio should send ACK message, here is a sample log from drachtio-server (192.168.0.87)

And here is eyebeam softphone with same trunk (192.168.1.50)

When creating rtpengine and b2bua, cannot create uas object but rtp and sip works, when destroying call, since it cannot find uas object, call cannot be disconnected automatically.
Here is Error:

Error proxying call with media: TypeError: Cannot destructure property uas of 'undefined' or 'null'.: TypeError: Cannot destructure property uas of 'undefined' or 'null'.
at rtpengine.offer.then.then.then (C:\TFS\vcp\vcp.B2BUAVirtualPbx\app.js:266:19)

Here is Code:

        dest = `sip:${uri.user}@${config.get('destination')}`;
        var trunk = config.get("trunks")[0];
        //dest = `sip:${config.get('FromAccount')}@${config.get('destination')}`

        //req.callingNumber = config.get('FromAccount');

        rtpengine.offer(locRtp, Object.assign(details, { 'sdp': req.body, 'record call': 'yes' }))
            .then((rtpResponse) => {
                console.log(`got response from rtpengine: ${JSON.stringify(rtpResponse)}`);
                if (rtpResponse && rtpResponse.result === 'ok') return rtpResponse.sdp;
                throw new Error('rtpengine failure');
            })
            .then((sdpB) => {
                console.log(`rtpengine offer returned sdp ${sdpB}`);
                return srf.createB2BUA(req, res, dest, {
                    localSdpB: sdpB,
                    localSdpA: getSdpA.bind(null, details),
                    auth: {
                        username: trunk.username,
                        password: trunk.password
                    }
                })
                .catch((err) => {
                    console.log(`Error connecting call: ${err.message}`);
                });
            })
            .then(({ uas, uac }) => {
                console.log('call connected with media proxy');

                return endCall(uas, uac, details);
            })
            .catch((err) => {
                console.error(`Error proxying call with media: ${err}: ${err.stack}`);
            });

Document the server control protocol

Hi would be interested in controlling the Dachtio server via a non NodeJS control plane (such as Golang).
Such as https://github.com/tomponline/fsclient

Is there any documentation for the control protocol used by the Dachtio server?

Thanks!

Possible error on Content-Type Header detection

I'm trying to send DTMF in SIP INFO request and I always got a missing content-type error :

SipDialogController::doSendRequestInsideDialog - Error: missing content-type

In my Nodejs code I put a content-type header but it's not seen in sever part.

app.request({
method: 'INFO',
stackDialogId: dialog,
headers: {
'User-Agent': 'dracht.io',
'Content-Type': ' application/dtmf-relay'
},
body: messageBody
}, function(err, req){}

Looking at SipDialogController::doSendRequestInsideDialog line 177 I found that !searchForHeader( tags, siptag_content_type, contentType ) is using siptag_content_type and not siptag_content_type_str.
It may be the reason of issue in content-type header detection.

Outbound proxy support

It would come in handy if outbound messages can be forwarded to a proxy/gateway instead of the address contained in the SIP uri.

Providing Contact Header

Hi,

since we are struggling on NAT with out internal phones, we try to provide a predefined "Contact" Header ( <sip:192.168.100.200:23792>) for a INFO Request.
We try to send this Request, but it seems the DrachtServer sees our contact, but overrides it again outgoing_update_contact() outgoing_update_contact: updating contact to udp/172.22.17.11:5060

is there a way to supress this behavior, or to change the contact information for an dialog.

a little more context: we use RFC3581- symmetric response routing. Everything works as excpected, except the final BYE from Remote - so we try to update out contact informations to the informations provided by the responses earlier - using "port" and "received" in VIA Responses)

2018-12-07 10:06:14.256214 Client::processMessage - got request with 4 tokens
2018-12-07 10:06:14.256246 Client::processMessage - request id 4f030aa4-2b3c-4b7a-8b11-17f2f3539e32, request type: sip transaction id: , dialog id: bd60d3a0-a110-464b-9c65-283ed78e14a8
2018-12-07 10:06:14.256276 Client::processMessage - sending a request inside a dialog (dialogId provided)
2018-12-07 10:06:14.256705 ClientController::addAppTransaction: transactionId fe5ddf69-a2f2-4a02-b61f-5eb28c298ea6; size: 3
2018-12-07 10:06:14.256743 ClientController::addApiRequest: clientMsgId 4f030aa4-2b3c-4b7a-8b11-17f2f3539e32; size: 1
2018-12-07 10:06:14.256825 SipDialogController::doSendRequestInsideDialog dialog id: bd60d3a0-a110-464b-9c65-283ed78e14a8
2018-12-07 10:06:14.257058 makeTags - Adding well-known header 'contact' with value '<sip:192.168.100.200:23792>'
2018-12-07 10:06:14.257433 SipDialogController::doSendRequestInsideDialog - defaulting request uri to sip:192.168.100.53:5060
2018-12-07 10:06:14.257516 nta.c:2753 nta_tpn_by_url() nta: selecting scheme sip
2018-12-07 10:06:14.257691 nta.c:2595 outgoing_update_contact() outgoing_update_contact: updating contact to  udp/172.22.17.11:5060
2018-12-07 10:06:14.257905 tport.c:3285 tport_tsend() tport_tsend(0x12324a0) tpn = */192.168.100.53:5060
2018-12-07 10:06:14.257946 tport.c:4085 tport_resolve() tport_resolve addrinfo = 192.168.100.53:5060
2018-12-07 10:06:14.258382 tport.c:3531 tport_send_msg() tport_vsend returned 351
2018-12-07 10:06:14.258480 send 351 bytes to udp/[192.168.100.53]:5060 at 10:06:14.258058:
INFO sip:192.168.100.53:5060 SIP/2.0```

Active sessions stats

I'm looking for a stat that represents the number of active sessions Drachtio currently has in-flight but I do not see anything in the existing watchdog dump to reflect this nor can I see a way to calculate this from the existing data. This seems to be the case for both server and apps.

Would it be possible to expose Sofia stats? Or is there another way one could produce a metric to reflect how many sessions the server "thinks" are still active?

Thanks!

assertion fails crash multiple cancel for the same invite

Was just testing dockerize environment and pushing a few calls between two UAs both are WebRTC clients on mobile networks. After pushing several calls successfully i noticed a crash.

crash log: https://gist.github.com/andrewvmail/fbbdcd78e3ee8b6d4b7601121faf9e54

Confused on license

Hi Dave,

I can see the project is MIT ( per LICENSE file ) but I also see a GPLv3 file in docs/COPYING. What does the docs/COPYING file relate to?

Preloaded SIP Route Header

Hola,

Im just getting my feet wet with drachtio. Excellent work BTW!

Im currently playing it to register video endpoints. Have an endpoint registering just fine drachtio-server and using drachtio node app to control it. Im using your example proxy to make a call into my Cisco VCS. Its not liking the pre-loaded route header: here is someone with a similar issue: https://supportforums.cisco.com/t5/telepresence/vcse-not-accepting-pre-loaded-route-headers/td-p/2092815

ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP 192.168.128.157:5060;branch=z9hG4bKcdfdf881e45c0f13fd07c17075cb2552.1;rport
Call-ID: c8ef678f9cb9ce34f8837034e1e7e0e2
CSeq: 100 ACK
From: "Jason" sip:192.168.128.157;tag=dce97f2424beec6b
To: sip:[email protected];tag=46e70211d08baf70
Route: sip:18.X.X.76;lr <-------- This is what VCS is not liking, it wanting it to be the IP of VCS.
User-Agent: TANDBERG/520 (TC7.1.4.908e4a9)
Content-Length: 0

I tried replacing the header, but no joy.

Any thoughts?

Thanks!

memory leak in client controller

scenario: B2B, then BYE from B leg, BYE sent on A leg, all timers processed, but there is still an entry in the app transactions map:

2017-09-19 13:10:40.337086 m_mapAppTransactions size: 1

Can't run make, line 81: aclocal-1.14: command not found

I have installed autoconf, m4 and automake. Yet running the "make" command yields the following results:

line 81: aclocal-1.14: command not found
WARNING: 'aclocal-1.14' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [../aclocal.m4] Error 127

Server crashes on broken WebSocket connection

Case: I'm connecting to drachtio-server (using docker image) from an Electron app through WebSocket (ws protocol, using SIP.js npm lib without hack* options given to the user agent), and if I quit the Electron app while the connection is running (and don't wait for the connection to close), drachtio-server seems to crash. The docker image restarts upon drachtio-server crashing.

Down below is what I'm seeing in the logs. In there MYCLIENTIPHERE can point to either registrar or my Electron client, I'm running both the registrar (drachtio-srf) and client (sip.js) locally.

Client::read_handler read: cdc6f3af-3171-4e7e-8a76-1471f1c6cfb9|sip|02ef1299-1871-48f5-9d67-638d759f836a|
SIP/2.0 200 OK
Call-ID: 056daea8-5b92-1236-70be-00505697cfeb
cseq: 116299113 BYE
from: <sip:[email protected]>;tag=9qbrld4l0g
to: <sip:MYDRACHTIOSERVERIPHERE:445;transport=ws>;tag=7F0ep29c7c1Ha
Content-Length: 0


Client::read_handler read: cdc6f3af-3171-4e7e-8a76-1471f1c6cfb9|sip|02ef1299-1871-48f5-9d67-638d759f836a|
SIP/2.0 200 OK
Call-ID: 056daea8-5b92-1236-70be-00505697cfeb
cseq: 116299113 BYE
from: <sip:[email protected]>;tag=9qbrld4l0g
to: <sip:MYDRACHTIOSERVERIPHERE:445;transport=ws>;tag=7F0ep29c7c1Ha
Content-Length: 0

Client::processMessage - got request with 4 tokens
Client::processMessage - request id cdc6f3af-3171-4e7e-8a76-1471f1c6cfb9, request type: sip transaction id: 02ef1299-1871-48f5-9d67-638d759f836a, dialog id:
ClientController::addApiRequest: clientMsgId cdc6f3af-3171-4e7e-8a76-1471f1c6cfb9; size: 1
SipDialogController::doRespondToSipRequest found incoming transaction 0x17c6c20
SipDialogController::doRespondToSipRequest - contact header: <sip:MYDRACHTIOSERVERIPHERE:445;transport=ws>
makeTags - Adding well-known header 'Call-ID' with value '056daea8-5b92-1236-70be-00505697cfeb'
makeTags - Adding well-known header 'cseq' with value '116299113 BYE'
makeTags - Adding well-known header 'from' with value '<sip:[email protected]>;tag=9qbrld4l0g'
makeTags - Adding well-known header 'to' with value '<sip:MYDRACHTIOSERVERIPHERE:445;transport=ws>;tag=7F0ep29c7c1Ha'
tport.c:3285 tport_tsend() tport_tsend(0x7f50e1823010) tpn = WS/MYCLIENTIPHERE:52547
tport.c:4085 tport_resolve() tport_resolve addrinfo = MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cd480): not found by name WS/MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cd940): not found by name WS/MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cde00): not found by name WS/MYCLIENTIPHERE:52547
tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x17ccfc0): new secondary tport 0x7f50e1802010
tport.c:1002 tport_base_connect() tport_base_connect(0x17ccfc0): what(pf=2 ws/[MYCLIENTIPHERE]:52547): Broken pipe
tport.c:3412 tport_tsend() tport_socket failed in tsend
nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Broken pipe(retrying)
tport.c:3285 tport_tsend() tport_tsend(0x17ccfc0) tpn = WS/MYCLIENTIPHERE:52547
tport.c:4085 tport_resolve() tport_resolve addrinfo = MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cd480): not found by name WS/MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cd940): not found by name WS/MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cde00): not found by name WS/MYCLIENTIPHERE:52547
tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x17ccfc0): new secondary tport 0x17d6a90
tport.c:1002 tport_base_connect() tport_base_connect(0x17ccfc0): what(pf=2 ws/[MYCLIENTIPHERE]:52547): Broken pipe
tport.c:3412 tport_tsend() tport_socket failed in tsend
nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Broken pipe(retrying)
tport.c:3285 tport_tsend() tport_tsend(0x17ccfc0) tpn = WS/MYCLIENTIPHERE:52547
tport.c:4085 tport_resolve() tport_resolve addrinfo = MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cd480): not found by name WS/MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cd940): not found by name WS/MYCLIENTIPHERE:52547
tport.c:4730 tport_by_addrinfo() tport_by_addrinfo(0x17cde00): not found by name WS/MYCLIENTIPHERE:52547
tport.c:880 tport_alloc_secondary() tport_alloc_secondary(0x17ccfc0): new secondary tport 0x17d6a90
tport.c:1002 tport_base_connect() tport_base_connect(0x17ccfc0): what(pf=2 ws/[MYCLIENTIPHERE]:52547): Broken pipe
tport.c:3412 tport_tsend() tport_socket failed in tsend
nta.c:6853 incoming_reply() incoming_reply: tport_tsend: Broken pipe(retrying)
nta.c:6865 incoming_reply() incoming_reply: tport_tsend: error (Broken pipe) while sending 200 OK for BYE (116299113)
SipDialogController::doRespondToSipRequest destroying irq 0x17c6c20

I've got sofia-loglevel at 9 and loglevel at debug, is there any way to get more logs out?

It might be that I'm sending another REGISTER from the client after a BYE message, I'll be poking around a bit more what's going on.

If you wish I'll see if I can come up with a repository for testing this easily.

B2BUA ACK being sent to wrong address

We have an issue with a B2BUA session sending the ACK for the B-leg to the wrong (nat-ed) address of the next hop (proxy). Running v0.8.0-rc4
I have attached a redacted log excerpt showing the 200 OK coming in from the proxy in response to the INVITE. The IP that the message was sent from was 10.0.26.232:6080.
The Record-Route has a value of "sip:PROXY-EXTERNAL_IP:6080;lr;ftag=3KgvX66j3Q8vQ;nat=yes"

The issue is that the ACK is being sent to the PROXY-EXTERNAL_IP instead of the 10.0.26.232 IP.
Is there some setting/config that we are missing to make Drachtio honor the nat=yes in the route?
drachtio-log-edited.txt

Proxy crash in cluster-experimental branch

I am using drachtio-srf and when handling INVITE requests, I call the srf.proxyRequest() function to enable the proxy. When using the master branch, it works as expected. When using the cluster-experimental branch, drachtio-server gives a segmentation fault. I think the basic drachtio proxy implementation gives the same result.

I am attaching the server log. I can't see much from it. The callflow is a registration of two clients (with passport authentication), then one invites the other.

Server versions tested:
master: 0.5.0-122-g3a17efc
cluster-experimental: 0.7.1-rc2-5-g3072a12

If you need more details, please let me know.

Thanks.

drachtio_proxy_crash.txt

server should add a Contact header to REFER if necessary

A succesful REFER request creates an implicit subscription, but a Contact header is needed in order for the receiving UA to know where to send NOTIFY messages

DrachtIO-Server crashes after sip-call with excluded transport

We had excluded tcp from out drachtio-server.
If we try to use this transport the drachtserver crashes

Last lines from Docker-Log

2018-12-06 13:10:28.884319 Client::processMessage - got request with 4 tokens
2018-12-06 13:10:28.884420 Client::processMessage - request id b688dca4-8554-49fb-81ae-708b034c0a60, request type: sip transaction id: , dialog id: c5640f56-bec1-4379-af49-b19d9674aed1
2018-12-06 13:10:28.884458 Client::processMessage - sending a request inside a dialog (dialogId provided)
2018-12-06 13:10:28.884626 ClientController::addApiRequest: clientMsgId b688dca4-8554-49fb-81ae-708b034c0a60; size: 1
2018-12-06 13:10:28.884699 SipDialogController::doSendRequestInsideDialog dialog id: c5640f56-bec1-4379-af49-b19d9674aed1
2018-12-06 13:10:28.884957 SipDialogController::doSendRequestInsideDialog - defaulting request uri to sip:[email protected]:5038;transport=udp
2018-12-06 13:10:28.884997 DrachtioController::findTportForSubscription: no transport found for [email protected]
2018-12-06 13:10:28.885030 SipDialogController::doSendRequestInsideDialog - automatically detecting content-type as application/sdp
2018-12-06 13:10:28.885088 nta.c:2753 nta_tpn_by_url() nta: selecting scheme sip
2018-12-06 13:10:28.885142 tport.c:3285 tport_tsend() tport_tsend(0x19796e0) tpn = udp/172.22.17.11:5038
2018-12-06 13:10:28.885182 tport.c:4085 tport_resolve() tport_resolve addrinfo = 172.22.17.11:5038
2018-12-06 13:10:28.886871 tport.c:3531 tport_send_msg() tport_vsend returned 895
2018-12-06 13:10:28.887211 send 895 bytes to udp/[172.22.17.11]:5038 at 13:10:28.885221:
ACK sip:[email protected]:5038;transport=udp SIP/2.0
Via: SIP/2.0/UDP 172.22.17.11;rport;branch=z9hG4bK75e5tFpNKKXer
Max-Forwards: 70
From: <sip:172.22.17.11:5060>;tag=6FHF0NeQppcKp
To: <sip:[email protected]:5038>;tag=7vZt4a8gFm1mH
Call-ID: 24ea3c27-73fb-1237-30aa-3ac0b2717a22
CSeq: 131714850 ACK
Content-Type: application/sdp
Content-Length: 527

v=0
o=FreeSWITCH 1544081341 1544081342 IN IP4 0.0.0.0
s=FreeSWITCH
c=IN IP4 0.0.0.0
t=0 0
m=audio 20486 RTP/AVP 0 102 103 8 101 104 106
a=rtpmap:0 PCMU/8000
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=0; cbr=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=rtpmap:103 SPEEX/32000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:104 telephone-event/48000
a=fmtp:104 0-16
a=rtpmap:106 telephone-event/32000
a=fmtp:106 0-16
a=ptime:20
2018-12-06 13:10:28.891731 nta.c:8405 outgoing_send() nta: sent ACK (131714850) to udp/172.22.17.11:5038
2018-12-06 13:10:28.891805 SipDialogController::doSendRequestInsideDialog - clearing IIP that we generated as uac
2018-12-06 13:10:28.891844 SipDialogController::clearIIP - setting Timer D to keep transaction around for retransmits on leg 0x197ccf0
2018-12-06 13:10:28.891883 timerD: Adding entry to go off in 32500ms
2018-12-06 13:10:28.891916 timerD: Adding entry to the head (queue was empty), length: 1
2018-12-06 13:10:28.891970 ClientController::removeApiRequest: clientMsgId b688dca4-8554-49fb-81ae-708b034c0a60; size: 0
2018-12-06 13:10:28.892713 Client::write_handler - wrote 1089 bytes: system:0
2018-12-06 13:10:28.972202 Client::read_handler read: 0a058eb7-0071-47e9-a9d4-d9a8aa4c9e53|sip||
INVITE sip:192.168.100.53;transport=tcp SIP/2.0
From: sip:[email protected]
Alert-Info: file://ring.pcm/;info=alert-autoanswer
Content-Length: 549

v=0
o=FreeSWITCH 1544081341 1544081342 IN IP4 172.22.17.11
s=FreeSWITCH
c=IN IP4 172.22.17.11
t=0 0
m=audio 20486 RTP/AVP 0 102 103 8 101 104 106
a=rtpmap:0 PCMU/8000
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=0; cbr=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40
a=rtpmap:103 SPEEX/32000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:104 telephone-event/48000
a=fmtp:104 0-16
a=rtpmap:106 telephone-event/32000
a=fmtp:106 0-16
a=ptime:20
a=sendrecv


2018-12-06 13:10:28.976671 Client::processMessage - got request with 4 tokens
2018-12-06 13:10:28.976822 Client::processMessage - request id 0a058eb7-0071-47e9-a9d4-d9a8aa4c9e53, request type: sip transaction id: , dialog id:
2018-12-06 13:10:28.976979 Client::processMessage - sending a request outside of a dialog
2018-12-06 13:10:28.977325 ClientController::addAppTransaction: transactionId 85d4399a-8c9d-4605-8ee7-be07c5e98f0a; size: 1
2018-12-06 13:10:28.977441 ClientController::addApiRequest: clientMsgId 0a058eb7-0071-47e9-a9d4-d9a8aa4c9e53; size: 1
2018-12-06 13:10:28.977807 SipProxyController::doSendRequestOutsideDialog attempting to determine transport tport for request-uri sip:192.168.100.53;transport=tcp
proto: tcp
2018-12-06 13:10:28.977929 SipTransport::findAppropriateTransport: searching for a transport to reach tcp/sip:192.168.100.53;transport=tcp
2018-12-06 13:10:28.983340 SipTransport::findAppropriateTransport: host parsed as 192.168.100.53
2018-12-06 13:10:28.988989 SipTransport::findAppropriateTransport - after filtering for transport we have 4 candidates
2018-12-06 13:10:28.989119 SipTransport::findAppropriateTransport - after filtering for protocol we have 0 candidates

Feature Request: add a SSL/TLS-encrypted admin port so that the control messages aren't sent in plain text

This could be accomplished using third-party software such as HAProxy to provide an SSL-termination TCP endpoint.

However, it could be rather useful to provide out-of-the box encryption. It looks like the libraries are already included in the project for SIP over TLS.

Is this something on the "roadmap"?

Handling ISUP Messages

Hi,

Does DrachtIO server is able to handle ISUP Messages over SIP (as defined in RFC https://www.rfc-editor.org/rfc/rfc3372.txt) to receive PSTN call informations from PSTN Gateways.

It seems (if the gateway supports this behaviour) the ISUP Message should be transported within a Multipart body?

Segmentation fault while trying to run drachtio

application is crashing at drachtio.cpp line 253
std::regex re("^|^:]+)(?::(\\d+))?(?:;([^>]+))?>?$");

I have build on CentOS 6 by following commands

git clone --depth=50 --branch=develop git://github.com/davehorton/drachtio-server.git && cd drachtio-server
git submodule update --init --recursive
./bootstrap.sh
mkdir build && cd $_
../configure CPPFLAGS='-DNDEBUG'
make
sudo make install

config file is placed at
/etc/drachtio.conf.xml

running from
/usr/local/bin/drachtio

No events hitting syslog

I can't seem to get any messages to hit a local syslog server - it just appears that nothing is being sent from Drachtio. Nothing in the logs on full verbosity indicate a problem and both file logging and console sending seem to behave fine.
I've verified the local syslog server is listening & accepting other localhost requests.

Have i missed something or is there anything else I can explore to validate what Drachtio is doing (or not) with syslog sending?

       <syslog>
            <address>127.0.0.1</address>
            <port>515</port>
            <facility>local6</facility>
        </syslog>

Version: drachtio-server-v0.8.0-rc1

Thanks!

Gareth

Need to set "Contact" header

I am creating an app that uses srf.createUasDialog - I cant seems to override the Contact header if I add it to options, it looks correct in the agent send, but on the wire received by the UAC is both the original (wrong) contact and my contact.
Is there a way to do this?

drachtio / drachtio-server Goto Github PK

drachtio-server's Introduction

drachtio-server [

Docker

Ansible

Building from source

Building with tcmalloc

Platform support and dependencies

Installing

Configuring

Overview

SIP

Admin port

Logging

Monitoring

Homer

Prometheus.io

Fail2ban integration

drachtio-server's People

Contributors

Stargazers

Watchers

Forkers

drachtio-server's Issues

Recommend Projects

Recommend Topics

Recommend Org