Horace Miles created OPENMEETINGS-2810:
------------------------------------------
Summary: OM Sip Integration
Key: OPENMEETINGS-2810
URL: https://issues.apache.org/jira/browse/OPENMEETINGS-2810
Project: Openmeetings
Issue Type: Bug
Components: VoIP/SIP
Affects Versions: 7.2.0
Reporter: Horace Miles
Assignee: Maxim Solodovnik
Here is a **developer-focused version with sequence flow** you can send.
---
# Subject
OpenMeetings 7.2.0 on Java 17 with Asterisk 18: SIP bridge leg never
auto-originates, only `ConfbridgeList` is sent over AMI
Hello OpenMeetings team,
I am troubleshooting SIP conference integration with OpenMeetings 7.2.0 and
Asterisk 18.x. I have narrowed the issue down quite a bit and wanted to provide
a clean technical report.
## Environment
* OpenMeetings: 7.2.0
* Java: OpenJDK 17
* Asterisk: 18.x
* SIP stack: PJSIP
* OS: Ubuntu Linux
* AMI connection: localhost `127.0.0.1:5038`
* AMI user: `openmeetings`
## Problem summary
OpenMeetings successfully connects to Asterisk AMI and repeatedly sends
`ConfbridgeList` for the room conference number, but it never sends the
expected `Originate` action that would create the OpenMeetings SIP bridge leg.
As a result, the OM-side participant never joins the conference automatically
when the moderator enters the room.
## What works
The Asterisk side is working.
I can manually create the OM bridge leg with:
```bash
sudo asterisk -rx "channel originate Local/40011@rooms-omsip application Wait
60"
```
That successfully produces this in `confbridge list 40011`:
```text
Local/40011@rooms-omsip-... omsip_user
PJSIP/voipms-... sip_user
```
So the following are confirmed good:
* ConfBridge itself
* the `omsip_user` profile
* the dialplan logic for `rooms-omsip`
* coexistence of external SIP caller + OM bridge leg in the same conference
## Dialplan currently in use
```asterisk
[rooms-originate]
exten => _400XX!,1,Confbridge(${EXTEN},default_bridge,sip_user)
same => n,Hangup()
[rooms-omsip]
exten =>
_400XX!,1,GotoIf($[${DB_EXISTS(openmeetings/rooms/${EXTEN})}]?ok:notavail)
same => n(ok),Confbridge(${EXTEN},default_bridge,omsip_user)
same => n(notavail),Hangup()
```
## What AMI debug shows
With:
```asterisk
manager set debug on
```
I consistently see this pattern:
```text
Manager 'openmeetings' logged on
Action: Challenge
Action: Login
Action: CoreSettings
Action: Command (core show version)
Action: ConfbridgeList conference:40011
Action: ConfbridgeList conference:40011
Action: ConfbridgeList conference:40011
Manager 'openmeetings' logged off
```
This cycle repeats continuously.
What I do **not** see at any point is:
```text
Action: Originate
Channel: Local/40011@rooms-originate
```
So OpenMeetings is clearly talking to AMI, but it is only polling conference
state and never creating the SIP bridge leg.
## Class inspection
I inspected the compiled classes in my installed 7.2.0 jars and found the
relevant SIP code paths.
`SipManager.class` contains references to:
```text
OriginateAction
Local/%s@rooms-originate
ConfbridgeListAction
ManagerConnection
ManagerConnectionFactory
```
Relevant classes present in the installation include:
```text
org/apache/openmeetings/core/sip/SipManager.class
org/apache/openmeetings/core/sip/SipStackProcessor.class
org/apache/openmeetings/core/sip/ISipCallbacks.class
org/apache/openmeetings/db/entity/user/AsteriskSipUser.class
org/apache/openmeetings/web/room/menu/SipDialerDialog.class
org/apache/openmeetings/web/room/RoomPanel.class
```
This suggests the originate code is compiled in, but not being triggered in my
runtime path.
## Sequence flow as observed
### Expected flow
```text
Moderator enters room
->
OpenMeetings room/moderator logic detects moderated room state
->
SipManager issues AMI OriginateAction
->
Asterisk creates Local/40011@rooms-originate
->
Dialplan joins ConfBridge
->
OM bridge leg appears as omsip_user
```
### Actual flow
```text
Moderator enters room
->
OpenMeetings connects to AMI
->
AMI Login succeeds
->
OpenMeetings sends CoreSettings and core show version
->
OpenMeetings repeatedly sends ConfbridgeList for 40011
->
AMI session logs off
->
reconnect / repeat
```
There is never an `OriginateAction`.
## Additional context
I originally saw `asterisk-java` warnings related to
`ChallengeResponseFailedEvent` parsing during heavy SIP scanner traffic. I have
since implemented fail2ban and IP blocking, so the scanner noise is now much
lower, but the core problem remains: OpenMeetings still does not send
`Originate`.
I also downgraded from Java 21 to Java 17, since OM 7.2.0 is aligned with Java
17. That stabilized some unrelated media behavior, but did not change the
missing originate behavior.
## Main question for the developers
Could you please clarify:
1. Under what exact condition does `SipManager` issue `OriginateAction`?
2. Is the originate path supposed to happen automatically when a moderator
enters a moderated room?
3. Is the originate path only triggered through `SipDialerDialog` / manual SIP
dialing UI?
4. Is there an additional room flag, SIP setting, or DB state required before
automatic originate is allowed?
5. Is the repeated AMI logout/login cycle normal, or does it indicate the SIP
manager component is restarting/failing?
## Most important point
The issue does **not** appear to be on the Asterisk side, because manual Local
originate into the OM profile works correctly. The missing behavior is
specifically that OpenMeetings never sends `Originate` over AMI.
If helpful, I can also provide:
* full AMI debug trace
* `SipManager.class` string dump
* exact `confbridge list` output
* exact dialplan sections used in the test
Thank you.
---
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
