Unable to send in-dialog request

I have a server that was running fine on Asterisk 16. I wanted to do some work on the source code so I switched over to the current master branch and since that recompile I have been having this issue:

[May 15 14:13:50] WARNING[896]: res_pjsip.c:1301 send_in_dialog_request: Unable to send in-dialog request.

This is printed to the console whenever Asterisk tries to make any type of in-dialog request to the PJSIP endpoint (WebRTC if that’s relevant) such as re-invites, when SendText is called from the dialplan or for the confbridge enhanced messaging events.

I’ve confirmed that the client works fine with when connected to another similar Asterisk server. I have also ruled out anything strange in the dialplan by stripping it right back to a single line.

The really strange thing is I have tried both Asterisk 18 and Asterisk 16, the same version I originally had everything working on and I get the same result.

I am building Asterisk with bundled pjproject and jansson

./configure --with-pjproject-bundled --with-jansson-bundled

This isn’t something that I’ve seen before in my 10 years working with Asterisk and it has me a little stumped…

Any idea’s what things I should check next to figure out the cause of this issue? The log message doesn’t really point me in any particular direction.

I would suggest getting a debug log[1] as they may provide better detail into it. Is the client directly connected to Asterisk? What is the configuration?

[1] Collecting Debug Information - Asterisk Project - Asterisk Project Wiki

I believe this is the relevant excerpt from the debug log (I can post a full one if you think I’m missing something)

[May 16 08:05:57] DEBUG[21590][C-00000005] chan_pjsip.c: Sending MESSAGE from ‘1’ to ‘:PJSIP/dmc-live-call-00000004’: {
“type”: “ConfbridgeWelcome”,
“timestamp”: “2023-05-16T08:05:57.545+0000”,
“bridge”: {
“id”: “620788a5-fee5-4792-9f25-3fb2aeacc47d”,
“name”: “1”,
“creationtime”: “2023-05-16T08:05:54.381+0000”,
“video_mode”: “sfu”
“channels”: [
“id”: “yo26-hv02-dmc-coredev-ast01.dmcip.net-1684224353.16”,
“name”: “PJSIP/dmc-live-call-00000004”,
“state”: “Up”,
“caller”: {
“name”: “Live Call User”,
“number”: “abcd123”
“creationtime”: “2023-05-16T08:05:53.878+0000”,
“language”: “en”,
“admin”: false,
“muted”: false
[May 16 08:05:57] DEBUG[9356] res_pjsip/pjsip_resolver.c: Performing SIP DNS resolution of target ‘’
[May 16 08:05:57] DEBUG[9356] res_pjsip/pjsip_resolver.c: Transport type for target ‘’ is ‘(null)’
[May 16 08:05:57] DEBUG[9356] res_pjsip/pjsip_resolver.c: Target ‘’ is an IP address, skipping resolution
[May 16 08:05:57] DEBUG[9356] res_pjsip_session.c: Function session_inv_on_tsx_state_changed called on event TSX_STATE
[May 16 08:05:57] DEBUG[9356] res_pjsip_session.c: The state change pertains to the endpoint ‘dmc-live-call(PJSIP/dmc-live-call-00000004)’
[May 16 08:05:57] DEBUG[9356] res_pjsip_session.c: The inv session does NOT have an invite_tsx
[May 16 08:05:57] DEBUG[9356] res_pjsip_session.c: The UAC MESSAGE transaction involved in this state change is 0x2cf1c28
[May 16 08:05:57] DEBUG[9356] res_pjsip_session.c: The current transaction state is Terminated
[May 16 08:05:57] DEBUG[9356] res_pjsip_session.c: The transaction state change event is TRANSPORT_ERROR
[May 16 08:05:57] DEBUG[9356] res_pjsip_session.c: The current inv state is CONFIRMED

Does this indicate that Asterisk believes the websocket connection is down?

The client connects directly to the Asterisk websocket

This is the PJSIP configuration for the endpoint


match_header = X-DMC-Live-Call-Client: true



As far as I am aware this PJSIP configuration has not changed and was working for months prior to this issue occurring.

Is the Websocket still active?

Yes, the websocket connection is still active. The call stays online until I hang it up and this console message is not printed until the call is completed

WebSocket connection from ‘’ closed

For whatever reason a transport level error is occurring when sending the request. Why that is is not clear from the logging and would probably require someone being able to reproduce the issue and digging into it. There haven’t been any other reports of such an issue at this time.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.