[asterisk-bugs] [JIRA] (ASTERISK-22564) directmedia=no in sip.cnf seems to be ignored

[Jon Westgate (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210470#comment-210470 ] 

Jon Westgate commented on ASTERISK-22564:
-----------------------------------------

I forgot to mention the direction of no audio. 
[2001:8b0:0:30::5060:2] => 81.XXX.YYY.34 (no audio)
81.XXX.YYY.34 => [2001:8b0:0:30::5060:2] (working audio)

The test is to call my Cell via my IPV6 trunk. 
If I dial out via my trunk to my cellphone I get one way audio.
If I dial in from my cellphone via my trunk I get 2 way audio.
If I compile * without bridge_native_rtp I get 2 way audio when calling in and out.
                
> directmedia=no in sip.cnf seems to be ignored
> ---------------------------------------------
>
>                 Key: ASTERISK-22564
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22564
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Bridges/bridge_native_rtp
>    Affects Versions: 12.0.0-alpha1
>         Environment: linux_x64 debian with Asterisk SVN-trunk-r399533
>            Reporter: Jon Westgate
>
> I note that this has been reported before and was closed as not a bug.
> If this is not a bug, what is the correct way to disable native rtp_bridging on a per sip account basis?
> It used to be canreinvite=no.
> I can observe on 2 systems running asterisk 12/SVN-trunk-r399533 that with directmedia=no set on both sip trunk and sip client that this happens:
> – Executing [07974XXXXXX at wide:1] Dial("SIP/202-00000000", "SIP/JON_34XXXX/07974XXXXXX") in new stack
> == Using SIP RTP CoS mark 5
> – Called SIP/JON_34XXXX/07974XXXXXX
> > 0x7f0bdc018480 – Probation passed - setting RTP source address to [2XXX:XX0:0:X0::5060:2]:23569
> – SIP/JON_34XXXX-00000001 is ringing
> – SIP/JON_34XXXX-00000001 is making progress passing it to SIP/202-00000000
> > 0x7f0bdc018480 – Probation passed - setting RTP source address to [2XXX:XX0:0:X0::5060:2]:23569
> > 0x7f0bb003b470 – Probation passed - setting RTP source address to 8X.1X7.X85.X34:11794
> – SIP/JON_34XXXX-00000001 answered SIP/202-00000000
> – Channel SIP/202-00000000 joined 'simple_bridge' basic-bridge <4ff3502f-2411-410e-9f9f-eda20b8b1efb>
> – Channel SIP/JON_34XXXX-00000001 joined 'simple_bridge' basic-bridge <4ff3502f-2411-410e-9f9f-eda20b8b1efb>
> > Bridge 4ff3502f-2411-410e-9f9f-eda20b8b1efb: switching from simple_bridge technology to native_rtp
> – Channel SIP/JON_34XXXX-00000001 left 'native_rtp' basic-bridge <4ff3502f-2411-410e-9f9f-eda20b8b1efb>
> – Channel SIP/202-00000000 left 'native_rtp' basic-bridge <4ff3502f-2411-410e-9f9f-eda20b8b1efb>
> == Spawn extension (wide, 07974XXXXXX, 1) exited non-zero on 'SIP/202-00000000'
> In this case I have a provider who I connect to via IPV6 and my ip-phone is IPV4-only so a native rtp bridge is never going to work.
> however I would like native rtp bridge to work for internal calls.
> My outgoing sip trunk:
> [JON_34XXXX]
> type=peer
> remotesecret=password ; Our password to their service
> defaultuser=+44145XXXXXXX ; Authentication user for outbound
> host=voiceless.aa.net.uk
> canreinvite=no
> directmedia=no
> The phone's config
> [202]
> secret=xXxXxXxXxXxX
> username=202
> mailbox=202
> nat=force_rport,comedia
> type=friend
> context=wide
> host=dynamic
> canreinvite=no
> directmedia=no
> disallow=all
> allow=ulaw
> allow=gsm
> allow=alaw
> dtmfmode=rfc2833
> Note that this not only effects asterisk in its IPV6 <> IPV4 bridging modes but also in IPV4 <> IPV4.
> I have a scenario where phones exist on a NAT network and the phone server is straddled between an external IP and the internal network.
> This causes all kinds of one way audio and dropped calls after random timings.
> I guess there may actually be 2 bugs here:
> 1) Why does directmedia=no have no effect.
> 2) Why does rtp_bridge think it can bridge IPV4 and IPV6 rtp streams natively.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira