[Home]

Summary:ASTERISK-22127: Bridges/chan_sip: Directmedia settings not respected for setting up native_rtp bridge technology
Reporter:Jonathan Rose (jrose)Labels:
Date Opened:2013-07-19 17:04:20Date Closed:2013-07-24 08:44:12
Priority:MajorRegression?
Status:Closed/CompleteComponents:Bridges/bridge_native_rtp
Versions:SVN 12 Frequency of
Occurrence
Constant
Related
Issues:
is related toASTERISK-22128 ARI/bridges: chan_sip channels with directmedia=yes - Asterisk doesn't retake the media when the technology changes from native rtp
Environment:Attachments:
Description:With two SIP phones A and B both with directmedia=no, A calls B with no feature flags.
The bridge technology is native_rtp and SIP/A sends RTP directly to SIP/B and viceversa.

The same behavior is observed directmedia=yes
Comments:By: Jon Westgate (0ryn) 2013-09-20 14:51:54.370-0500

I'd like to know why this is not a bug?
If it's not a bug, what is the correct way to disable native rtp_bridging on a per sip account basis?
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@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