Skip to content

[BUG]: rtprelay-middleware returns 403 for from-pstn (PHONE_TO_PHONE) calls without contacting RTPEngine #321

New issue
New issue
Open
Open
[BUG]: rtprelay-middleware returns 403 for from-pstn (PHONE_TO_PHONE) calls without contacting RTPEngine#321
Labels
bug
@ramesh123456

Description

@ramesh123456
ramesh123456
opened on Dec 24, 2025

What happened?

Bug Description

The rtprelay-middleware returns 403 Forbidden for inbound PSTN calls (from-pstn routing direction) without contacting RTPEngine, while outbound calls (web-to-phone) work correctly.

Environment

  • Routr: fonoster/routr-one:latest
  • RTPEngine: fonoster/rtpengine:0.3.17
  • Architecture: PSTN Provider → Asterisk (UDP) → Routr → Voice App

Steps to Reproduce

  1. Configure a trunk in Routr pointing to Asterisk (UDP transport)
  2. Configure a DID number with aor_link pointing to a Voice App peer
  3. Send an INVITE from Asterisk (UDP) to Routr for the DID number
  4. Routr identifies routing as from-pstn correctly
  5. rtprelay-middleware returns 403 without forwarding to Voice App

Expected Behavior

  • rtprelay-middleware should process the INVITE
  • Call should be forwarded to the Voice App endpoint
  • RTPEngine should receive query and offer commands

Actual Behavior

  • rtprelay-middleware breaks the chain immediately
  • No (rtprelay) request log appears (unlike web-to-phone calls which show this log)
  • RTPEngine receives NO requests for inbound calls (confirmed with log-level=7)
  • 403 Forbidden returned to caller

Logs

Outbound call (WORKS):

(connect) routing request from: sip:[email protected], to: sip:[email protected] {"routingDirection":"agent-to-pstn"}
(dispatcher) sending request to middleware {"middlewareRef":"rtprelay-middleware"...}
(rtprelay) request {"direction":"web-to-phone","isNewCall":true,"type":"INVITE"}

RTPEngine logs show query and offer commands received ✅

Inbound call (FAILS):

(connect) routing request from: sip:[email protected], to: sip:+9140XXXXXXXX@XXXXXXX {"routingDirection":"from-pstn"}
(dispatcher) sending request to middleware {"middlewareRef":"rtprelay-middleware"...}
(dispatcher) found messageType to be responseType and broke the chain
  • No (rtprelay) request log
  • RTPEngine logs show NO requests received ❌

Analysis

Looking at the rtprelay code in /service/node_modules/@routr/rtprelay/dist/service.js:

if (shouldNotHandleRequest(req)) return res.send(req);
const direction = getDirectionFromRequest(req);  // Returns PHONE_TO_PHONE for UDP→UDP
const queryResponse = yield query(rtpeConfig)(req);  // <-- Fails here for inbound
logger.verbose("request", { direction, isNewCall, type });  // Never reached

The code fails at the query call before the logging statement. The exception is caught and returns 403.

Direction Detection Issue

From utils.js, direction is determined by transport:

  • WebSocket source → WEB_TO_PHONE or WEB_TO_WEB (works)
  • UDP source → PHONE_TO_PHONE or PHONE_TO_WEB

For PHONE_TO_PHONE (UDP→UDP), the rtprelay fails before contacting RTPEngine.

Configuration (verified correct)

-- Numbers
tel:+9140554545 → aor_link: sip:voice@office.fonoster.local
                  → trunk_ref: linked to trunk with inbound_uri: XXXXXXX

-- Peers  
Voice Server → aor: sip:voice@office.fonoster.local, contact_addr: XXXXX:50061
Asterisk PBX → aor: sip:asterisk@office.fonoster.local, contact_addr: XXXXXXX:5060

Connectivity Verified

  • RTPEngine UDP port 22222: Accessible ✅
  • RTPEngine HTTP port 8080: Accessible ✅
  • RTPENGINE_HOST=rtpengine, RTPENGINE_PORT=22222 configured ✅

Impact

This bug prevents using Fonoster/Routr for inbound PSTN calls to Voice Apps when the PSTN trunk connects via UDP (standard SIP). Only WebRTC-originated calls work.

Possible Fix

The rtprelay-middleware should handle PHONE_TO_PHONE direction the same way it handles other directions, or provide an option to bypass rtprelay for non-WebRTC calls.

Steps to reproduce

Bug Description

The rtprelay-middleware returns 403 Forbidden for inbound PSTN calls (from-pstn routing direction) without contacting RTPEngine, while outbound calls (web-to-phone) work correctly.

Environment

  • Routr: fonoster/routr-one:latest
  • RTPEngine: fonoster/rtpengine:0.3.17
  • Architecture: PSTN Provider → Asterisk (UDP) → Routr → Voice App

Steps to Reproduce

  1. Configure a trunk in Routr pointing to Asterisk (UDP transport)
  2. Configure a DID number with aor_link pointing to a Voice App peer
  3. Send an INVITE from Asterisk (UDP) to Routr for the DID number
  4. Routr identifies routing as from-pstn correctly
  5. rtprelay-middleware returns 403 without forwarding to Voice App

Expected Behavior

  • rtprelay-middleware should process the INVITE
  • Call should be forwarded to the Voice App endpoint
  • RTPEngine should receive query and offer commands

Actual Behavior

  • rtprelay-middleware breaks the chain immediately
  • No (rtprelay) request log appears (unlike web-to-phone calls which show this log)
  • RTPEngine receives NO requests for inbound calls (confirmed with log-level=7)
  • 403 Forbidden returned to caller

Logs

Outbound call (WORKS):

(connect) routing request from: sip:[email protected], to: sip:[email protected] {"routingDirection":"agent-to-pstn"}
(dispatcher) sending request to middleware {"middlewareRef":"rtprelay-middleware"...}
(rtprelay) request {"direction":"web-to-phone","isNewCall":true,"type":"INVITE"}

RTPEngine logs show query and offer commands received ✅

Inbound call (FAILS):

(connect) routing request from: sip:[email protected], to: sip:+9140XXXXXXXX@XXXXXXX {"routingDirection":"from-pstn"}
(dispatcher) sending request to middleware {"middlewareRef":"rtprelay-middleware"...}
(dispatcher) found messageType to be responseType and broke the chain
  • No (rtprelay) request log
  • RTPEngine logs show NO requests received ❌

Analysis

Looking at the rtprelay code in /service/node_modules/@routr/rtprelay/dist/service.js:

if (shouldNotHandleRequest(req)) return res.send(req);
const direction = getDirectionFromRequest(req);  // Returns PHONE_TO_PHONE for UDP→UDP
const queryResponse = yield query(rtpeConfig)(req);  // <-- Fails here for inbound
logger.verbose("request", { direction, isNewCall, type });  // Never reached

The code fails at the query call before the logging statement. The exception is caught and returns 403.

Direction Detection Issue

From utils.js, direction is determined by transport:

  • WebSocket source → WEB_TO_PHONE or WEB_TO_WEB (works)
  • UDP source → PHONE_TO_PHONE or PHONE_TO_WEB

For PHONE_TO_PHONE (UDP→UDP), the rtprelay fails before contacting RTPEngine.

Configuration (verified correct)

-- Numbers
tel:+9140554545 → aor_link: sip:voice@office.fonoster.local
                  → trunk_ref: linked to trunk with inbound_uri: XXXXXXX

-- Peers  
Voice Server → aor: sip:voice@office.fonoster.local, contact_addr: XXXXX:50061
Asterisk PBX → aor: sip:asterisk@office.fonoster.local, contact_addr: XXXXXXX:5060

Connectivity Verified

  • RTPEngine UDP port 22222: Accessible ✅
  • RTPEngine HTTP port 8080: Accessible ✅
  • RTPENGINE_HOST=rtpengine, RTPENGINE_PORT=22222 configured ✅

Impact

This bug prevents using Fonoster/Routr for inbound PSTN calls to Voice Apps when the PSTN trunk connects via UDP (standard SIP). Only WebRTC-originated calls work.

Possible Fix

The rtprelay-middleware should handle PHONE_TO_PHONE direction the same way it handles other directions, or provide an option to bypass rtprelay for non-WebRTC calls.

Expected behavior

Bug Description

The rtprelay-middleware returns 403 Forbidden for inbound PSTN calls (from-pstn routing direction) without contacting RTPEngine, while outbound calls (web-to-phone) work correctly.

Environment

  • Routr: fonoster/routr-one:latest
  • RTPEngine: fonoster/rtpengine:0.3.17
  • Architecture: PSTN Provider → Asterisk (UDP) → Routr → Voice App

Steps to Reproduce

  1. Configure a trunk in Routr pointing to Asterisk (UDP transport)
  2. Configure a DID number with aor_link pointing to a Voice App peer
  3. Send an INVITE from Asterisk (UDP) to Routr for the DID number
  4. Routr identifies routing as from-pstn correctly
  5. rtprelay-middleware returns 403 without forwarding to Voice App

Expected Behavior

  • rtprelay-middleware should process the INVITE
  • Call should be forwarded to the Voice App endpoint
  • RTPEngine should receive query and offer commands

Actual Behavior

  • rtprelay-middleware breaks the chain immediately
  • No (rtprelay) request log appears (unlike web-to-phone calls which show this log)
  • RTPEngine receives NO requests for inbound calls (confirmed with log-level=7)
  • 403 Forbidden returned to caller

Logs

Outbound call (WORKS):

(connect) routing request from: sip:[email protected], to: sip:[email protected] {"routingDirection":"agent-to-pstn"}
(dispatcher) sending request to middleware {"middlewareRef":"rtprelay-middleware"...}
(rtprelay) request {"direction":"web-to-phone","isNewCall":true,"type":"INVITE"}

RTPEngine logs show query and offer commands received ✅

Inbound call (FAILS):

(connect) routing request from: sip:[email protected], to: sip:+9140XXXXXXXX@XXXXXXX {"routingDirection":"from-pstn"}
(dispatcher) sending request to middleware {"middlewareRef":"rtprelay-middleware"...}
(dispatcher) found messageType to be responseType and broke the chain
  • No (rtprelay) request log
  • RTPEngine logs show NO requests received ❌

Analysis

Looking at the rtprelay code in /service/node_modules/@routr/rtprelay/dist/service.js:

if (shouldNotHandleRequest(req)) return res.send(req);
const direction = getDirectionFromRequest(req);  // Returns PHONE_TO_PHONE for UDP→UDP
const queryResponse = yield query(rtpeConfig)(req);  // <-- Fails here for inbound
logger.verbose("request", { direction, isNewCall, type });  // Never reached

The code fails at the query call before the logging statement. The exception is caught and returns 403.

Direction Detection Issue

From utils.js, direction is determined by transport:

  • WebSocket source → WEB_TO_PHONE or WEB_TO_WEB (works)
  • UDP source → PHONE_TO_PHONE or PHONE_TO_WEB

For PHONE_TO_PHONE (UDP→UDP), the rtprelay fails before contacting RTPEngine.

Configuration (verified correct)

-- Numbers
tel:+9140554545 → aor_link: sip:voice@office.fonoster.local
                  → trunk_ref: linked to trunk with inbound_uri: XXXXXXX

-- Peers  
Voice Server → aor: sip:voice@office.fonoster.local, contact_addr: XXXXX:50061
Asterisk PBX → aor: sip:asterisk@office.fonoster.local, contact_addr: XXXXXXX:5060

Connectivity Verified

  • RTPEngine UDP port 22222: Accessible ✅
  • RTPEngine HTTP port 8080: Accessible ✅
  • RTPENGINE_HOST=rtpengine, RTPENGINE_PORT=22222 configured ✅

Impact

This bug prevents using Fonoster/Routr for inbound PSTN calls to Voice Apps when the PSTN trunk connects via UDP (standard SIP). Only WebRTC-originated calls work.

Possible Fix

The rtprelay-middleware should handle PHONE_TO_PHONE direction the same way it handles other directions, or provide an option to bypass rtprelay for non-WebRTC calls.

Additional context

Bug Description

The rtprelay-middleware returns 403 Forbidden for inbound PSTN calls (from-pstn routing direction) without contacting RTPEngine, while outbound calls (web-to-phone) work correctly.

Environment

  • Routr: fonoster/routr-one:latest
  • RTPEngine: fonoster/rtpengine:0.3.17
  • Architecture: PSTN Provider → Asterisk (UDP) → Routr → Voice App

Steps to Reproduce

  1. Configure a trunk in Routr pointing to Asterisk (UDP transport)
  2. Configure a DID number with aor_link pointing to a Voice App peer
  3. Send an INVITE from Asterisk (UDP) to Routr for the DID number
  4. Routr identifies routing as from-pstn correctly
  5. rtprelay-middleware returns 403 without forwarding to Voice App

Expected Behavior

  • rtprelay-middleware should process the INVITE
  • Call should be forwarded to the Voice App endpoint
  • RTPEngine should receive query and offer commands

Actual Behavior

  • rtprelay-middleware breaks the chain immediately
  • No (rtprelay) request log appears (unlike web-to-phone calls which show this log)
  • RTPEngine receives NO requests for inbound calls (confirmed with log-level=7)
  • 403 Forbidden returned to caller

Logs

Outbound call (WORKS):

(connect) routing request from: sip:[email protected], to: sip:[email protected] {"routingDirection":"agent-to-pstn"}
(dispatcher) sending request to middleware {"middlewareRef":"rtprelay-middleware"...}
(rtprelay) request {"direction":"web-to-phone","isNewCall":true,"type":"INVITE"}

RTPEngine logs show query and offer commands received ✅

Inbound call (FAILS):

(connect) routing request from: sip:[email protected], to: sip:+9140XXXXXXXX@XXXXXXX {"routingDirection":"from-pstn"}
(dispatcher) sending request to middleware {"middlewareRef":"rtprelay-middleware"...}
(dispatcher) found messageType to be responseType and broke the chain
  • No (rtprelay) request log
  • RTPEngine logs show NO requests received ❌

Analysis

Looking at the rtprelay code in /service/node_modules/@routr/rtprelay/dist/service.js:

if (shouldNotHandleRequest(req)) return res.send(req);
const direction = getDirectionFromRequest(req);  // Returns PHONE_TO_PHONE for UDP→UDP
const queryResponse = yield query(rtpeConfig)(req);  // <-- Fails here for inbound
logger.verbose("request", { direction, isNewCall, type });  // Never reached

The code fails at the query call before the logging statement. The exception is caught and returns 403.

Direction Detection Issue

From utils.js, direction is determined by transport:

  • WebSocket source → WEB_TO_PHONE or WEB_TO_WEB (works)
  • UDP source → PHONE_TO_PHONE or PHONE_TO_WEB

For PHONE_TO_PHONE (UDP→UDP), the rtprelay fails before contacting RTPEngine.

Configuration (verified correct)

-- Numbers
tel:+9140554545 → aor_link: sip:voice@office.fonoster.local
                  → trunk_ref: linked to trunk with inbound_uri: XXXXXXX

-- Peers  
Voice Server → aor: sip:voice@office.fonoster.local, contact_addr: XXXXX:50061
Asterisk PBX → aor: sip:asterisk@office.fonoster.local, contact_addr: XXXXXXX:5060

Connectivity Verified

  • RTPEngine UDP port 22222: Accessible ✅
  • RTPEngine HTTP port 8080: Accessible ✅
  • RTPENGINE_HOST=rtpengine, RTPENGINE_PORT=22222 configured ✅

Impact

This bug prevents using Fonoster/Routr for inbound PSTN calls to Voice Apps when the PSTN trunk connects via UDP (standard SIP). Only WebRTC-originated calls work.

Possible Fix

The rtprelay-middleware should handle PHONE_TO_PHONE direction the same way it handles other directions, or provide an option to bypass rtprelay for non-WebRTC calls.

Metadata

Metadata

Assignees

No one assigned

    Labels

    bug

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions