# In-dialog SIP INFO messages causing connections to be dropped **URL:** \ **Category:** Asterisk SIP\ **Created:** [October 15, 2026, 12:44pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795 "2026-10-15T12:44:26Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![dunky](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dunky](https://community.asterisk.org/u/dunky)\ **Post date:** [October 15, 2026, 12:44pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795/1 "2026-10-15T12:44:26Z")
Hi Everybody, This is my first post on this forum. After 3 minutes our VOIP provider is sending out SIP `INFO`packets and then drops the connection. When watching the debug logs I see three INFO messages coming it followed by a `BYE` message. A ticket with the provider replay came back as: > We have checked the affected call using a SIP trace. > > The call itself is established correctly and remains active for around three minutes. After approximately 180 seconds, our platform sends a SIP `INFO` request as part of the dead-call detection mechanism. > > On the carrier side, this request is answered correctly with `200 OK`. On the customer side, however, the `INFO` request is not answered. The request is retransmitted several times and, after the timeout, the call is terminated. > > What is particularly noticeable is that the subsequent `BYE` is immediately answered with `200 OK`. This means the Asterisk system is still reachable at SIP level, but the `INFO` request itself is apparently not being processed or answered. > > We therefore recommend checking the SIP configuration on the Asterisk side, in particular whether in-dialog SIP `INFO` requests are accepted and answered correctly. Based on the trace, this does not currently look like a general connectivity, codec or RTP issue. We are using PJSIP included in Asterisk 20.20.1 and `INFO` packets are allowed. The log shows: `Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, INFO, MESSAGE, REFER` My question is: What needs to be configured to respond to these `INFO` messages? Many thanks in advance. ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [October 15, 2026, 12:45pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795/2 "2026-10-15T12:45:33Z")
There’s the res\_pjsip\_empty\_info module, but otherwise you haven’t shown a SIP trace to show what the actual INFO packet is like so I can’t say if that is applicable. ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [October 15, 2026, 12:50pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795/3 "2026-10-15T12:50:18Z")
> [@dunky](#): > > On the carrier side, this request is answered correctly with `200 OK`. On the customer side, however, the `INFO` request is not answered This doesn’t make sense. If they are getting a 200 OK, that’s all they need. They can only get one 2xx response for a request. The only interim responses would be 1xx ones. ---
**Author:** ![keshavdutt](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/keshavdutt/32/10270_2.png) [@keshavdutt](https://community.asterisk.org/u/keshavdutt)\ **Post date:** [October 15, 2026, 5:21pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795/4 "2026-10-15T17:21:51Z")
The `Allow:` header is a red herring here — it advertises the methods the stack will _accept_, not that anything will _answer_ a given INFO. I think your carrier’s description is accurate and Asterisk is answering nothing at all, and the reason is worth knowing. In PJSIP an in-dialog INFO is answered only if a session supplement claims it. Two modules register one: - `res_pjsip_dtmf_info` — claims `application/dtmf`, `application/dtmf-relay` and `application/hook-flash`. For any other content type its handler returns “not handled”. - `res_pjsip_empty_info` — claims an INFO with **no Content-Type** and answers 200 OK. Its comment says it exists precisely because some SBCs send empty INFOs as keepalives. The catch is in `res_pjsip_session.c`. `session_on_rx_request()` decides whether to claim the request with `has_supplement()`, which returns true if _any_ supplement is registered for the method — and `res_pjsip_dtmf_info` is autoloaded, so every INFO is claimed. `handle_incoming_request()` then walks the supplements, each returns 0 because the content type is not theirs, and the function falls off the end without sending anything. Because the request was already claimed at the module level, pjproject’s dialog layer never gets to apply its own fallback (it would otherwise answer `500 Unhandled by dialog usages`). Net result: the INFO is swallowed silently — retransmissions, timeout, BYE, and the BYE answered 200 OK immediately because BYE is handled by the invite session itself. That is exactly the shape of what the carrier traced. So, in order: 1. `module show like info` on the CLI. If `res_pjsip_empty_info.so` is not loaded — a `noload`, or `autoload=no` in `modules.conf` — and the dead-call-detection INFO is bodyless, that single module is your answer. 2. If it _is_ loaded and you still get no response, the INFO carries a body of a type nothing claims. Post the INFO exactly as it arrives from `pjsip set logger on`, with the `Content-Type` and the body — that decides whether `res_pjsip_empty_info` applies at all or you need a small supplement of your own. Either way the trace @jcolp asked for is the thing that settles it, and the `Content-Type` line is the one that matters. Worth adding: dead-call detection over in-dialog INFO every 180 s is an odd choice by your provider. If they also support RFC 4028 session timers, `timers=yes` with sensible `timers_min_se` / `timers_sess_expires` on the endpoint gives them the same liveness check through a mechanism Asterisk implements fully, and takes the whole question away. ---
**Author:** ![jcolp](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/jcolp/32/8848_2.png) [@jcolp](https://community.asterisk.org/u/jcolp)\ **Post date:** [October 15, 2026, 6:38pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795/5 "2026-10-15T18:38:04Z")
@keshavdutt Are you replying to posts here using LLM output? If so, disclose it and also be aware that some individuals don’t like being responded to with the copy/paste of an LLM. ---
**Author:** ![dunky](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dunky](https://community.asterisk.org/u/dunky)\ **Post date:** [October 16, 2026, 3:30pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795/6 "2026-10-16T15:30:41Z")
Thank you everyone. The line: ```auto load = res_pjsip_empty_info.so ``` was not in `/etc/asterisk/modules.conf`. After adding it and restarting Asterisk the `INFO` messages are being replied to with an `OK` message. I checked using `tcpdump -i eth0 -w /tmp/sip2.pcap port 5060`and could see the `OK` messages being sent after the `INFO` message. Let the call continue for 9 minutes and the connection did not drop. Thanks for the help and the very quick responses. ---
**Author:** ![david551](https://avatars.discourse-cdn.com/v4/letter/d/3bc359/32.png) [@david551](https://community.asterisk.org/u/david551)\ **Post date:** [October 16, 2026, 4:15pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795/7 "2026-10-16T16:15:15Z")
Shouldn’t this be raised as an issue, as a UAS should never ignore requests, even if it doesn’t know what to do with them. ---
**Author:** ![dunky](https://avatars.discourse-cdn.com/v4/letter/d/258eb7/32.png) [@dunky](https://community.asterisk.org/u/dunky)\ **Post date:** [October 16, 2026, 7:54pm UTC](https://community.asterisk.org/t/in-dialog-sip-info-messages-causing-connections-to-be-dropped/114795/8 "2026-10-16T19:54:15Z")
I raised a ticket in the pjsip project and it was rejected. Asterisk was built from source and the `res_pjsip_empty_info.so` module was built. However, it was not included in the modules.conf. Maybe this has been fixed in a later version; I didn’t was to build the latest version without SIP, just in case.