asterisk users - Apr 2017 - pjsip direct_media=yes and "unknown" endpoints

I'm trying to implement direct_media between multiple peers and an
uplink provider, all of whom have direct_media=yes configures.

For originating calls to the uplink provider direct_media=yes works like
expected. SIP flows through asterisk, rtp doesn't

SIP: enduser <-> SBC <-> asterisk 13 <-> uplink
RTP: enduser <-> SBC <-----------------> uplink

SBC matches an endpoint based on ip and dials the uplink:

-- Executing [+31xxxxxxxxx at outgoingrr:9]
Dial("PJSIP/sbcs-00000092", "PJSIP/+31xxxxxxxxx at uplink")
in new stack
-- Called PJSIP/+31xxxxxxxxx at uplink
-- PJSIP/uplink-00000093 is making progress passing it to PJSIP/sbcs-00000092

-- PJSIP/uplink-00000093 answered PJSIP/sbcs-00000092
-- Channel PJSIP/uplink-00000093 joined 'simple_bridge' basic-bridge
<3b25c543-13a3-4d74-b2fe-7122a1cfe4a4>
-- Channel PJSIP/sbcs-00000092 joined 'simple_bridge' basic-bridge
<3b25c543-13a3-4d74-b2fe-7122a1cfe4a4>
   > Bridge 3b25c543-13a3-4d74-b2fe-7122a1cfe4a4: switching from
simple_bridge technology to native_rtp
   > Remotely bridged 'PJSIP/sbcs-00000092' and
'PJSIP/uplink-00000093' - media will flow directly between them
   > Remotely bridged 'PJSIP/sbcs-00000092' and
'PJSIP/uplink-00000093' - media will flow directly between them

Whoever when a terminating call comes in from the uplink provider, a sip
request is send to a redirector. The redirector has redirect_method=uri_core
configured (the only method that works for me).

-- Executing [+31xxxxxxxxx at incoming:11]
Dial("PJSIP/uplink-00000094", "PJSIP/+31xxxxxxxxx at
pathfinder") in new stack
-- Called PJSIP/+31xxxxxxxxx at pathfinder
-- Now forwarding PJSIP/uplink-00000094 to
'PJSIP/pathfinder/sip:+31xxxxxxxxx at sip.xxxxxx.nl' (thanks to
PJSIP/pathfinder-00000095)
...
-- PJSIP/pathfinder-00000096 answered PJSIP/uplink-00000094
-- Channel PJSIP/pathfinder-00000096 joined 'simple_bridge' basic-bridge
<1bf02059-ea8f-4f9c-bc33-8ae99ba45c9a>
-- Channel PJSIP/uplink-00000094 joined 'simple_bridge' basic-bridge
<1bf02059-ea8f-4f9c-bc33-8ae99ba45c9a>
...
-- Channel PJSIP/pathfinder-00000096 left 'simple_bridge' basic-bridge
<1bf02059-ea8f-4f9c-bc33-8ae99ba45c9a>
-- Channel PJSIP/uplink-00000094 left 'simple_bridge' basic-bridge
<1bf02059-ea8f-4f9c-bc33-8ae99ba45c9a>

The request now gets routed based on a fully qualified domainname (with
NAPTR/SRV records), which ultimately resolves to an ip that is matched in the
endpoint SBC used above to originate a call.  But now the asterisk stays in the
loop regarding RTP, a simple bridge is created but never switches to direct
media.

SIP: enduser <-> uplink <-> asterisk 13 <-> pathfinder (302
redirect)

SIP: enduser <-> uplink <-> asterisk 13 <-> sip.xxxxxx.nl
RTP: enduser <-> uplink <-> asterisk 13 <-> sip.xxxxxx.nl

Anybody got an idea why the last scenario fails to work?

On Wed, Apr 26, 2017, at 01:25 PM, Daniel Tryba wrote:

<snip>
> The request now gets routed based on a fully qualified domainname (with
> NAPTR/SRV records), which ultimately resolves to an ip that is matched in
> the
> endpoint SBC used above to originate a call.  But now the asterisk stays
> in the
> loop regarding RTP, a simple bridge is created but never switches to
> direct
> media.
> 
> SIP: enduser <-> uplink <-> asterisk 13 <-> pathfinder
(302 redirect)
> 
> SIP: enduser <-> uplink <-> asterisk 13 <-> sip.xxxxxx.nl
> RTP: enduser <-> uplink <-> asterisk 13 <-> sip.xxxxxx.nl
> 
> Anybody got an idea why the last scenario fails to work?
If you turn up core debug (core set debug 2) and ensure it is going to
the CLI then the bridge_native_rtp module will tell you why exactly it
can't native bridge. You might also want to do a core show channel on
both channels to see what the codecs are.

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

> > Anybody got an idea why the last scenario fails to work?
> 
> If you turn up core debug (core set debug 2) and ensure it is going to
> the CLI then the bridge_native_rtp module will tell you why exactly it
> can't native bridge. You might also want to do a core show channel on
> both channels to see what the codecs are.
Thanks for the hint, I wasn't seeing any debug since it wasn't getting
send to console. I'll take a better look and report back.

On Wed, Apr 26, 2017 at 06:25:43PM +0200, Daniel Tryba
wrote:
> Whoever when a terminating call comes in from the uplink provider, a
> sip request is send to a redirector. The redirector has
> redirect_method=uri_core configured (the only method that works for
> me).
[...]
> The request now gets routed based on a fully qualified domainname
> (with NAPTR/SRV records), which ultimately resolves to an ip that is
> matched in the endpoint SBC used above to originate a call.  But now
> the asterisk stays in the loop regarding RTP, a simple bridge is
> created but never switches to direct media.
This is not an asterisk problem, after fiddling with the config and
using templates to make sure the config for all (configured) endpoints
was the same, a reINVITE renegotiated RTP between the endpoints. 

However what happens is that after the renegotiation the DTMF
payloadtype (rfc4733) changed from 101 in the initial setup to 96. The
uplink provider doesn't support this thus DTMF breaks making
direct_media not an option right now. Something I have to figure out
later.