[Home]

Summary:ASTERISK-20333: 'directmedia' not working any more
Reporter:Maciej Krajewski (jamicque)Labels:
Date Opened:2012-08-29 08:28:42Date Closed:2012-10-02 15:30:10
Priority:MajorRegression?Yes
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:1.8.15.0 Frequency of
Occurrence		Constant
Related
Issues:
is caused byASTERISK-20409 sip_tech_info channels cannot be bridged, not even with themselves
Environment:Attachments:( 0) directmedia.cap
( 1) full
( 2) full+sipdebug.log
( 3) sip.conf
( 4) sippeers_propper.txt
( 5) sippeers.csv
Description:I've updated me asterisk today from 1.8.13.1 to 1.8.15.0,, what I've noticed is that directmedia has stopped working.
I'm using realtime peer configuration, I have directmedia set to yes on both friends calling each other (simple dial without any options).
{code}
exten => 1,1,Dial(SIP/test002)
same => n,Hangup()
{code}

Configured peers has dtmfmode set to "info" (I know this is an issue that direct media ins not working if set to rfc2833 or inbound).

When I've downgraded asterisk to 1.8.13.1 the directmedia has worked again. I've done some investigation and what I  have found is that some change between 1.8.13.1 and 1.8.14.0 has done that.

I've attached the logs from asterisk 1.8.15.0
Comments:By: Matt Jordan (mjordan) 2012-08-29 09:18:50.811-0500

Please attach the relevant portion of your sip.conf for the peers in question.
By: Maciej Krajewski (jamicque) 2012-08-29 09:24:57.122-0500

realtime configuration
By: Maciej Krajewski (jamicque) 2012-08-29 09:25:16.029-0500

I've attached the realtime configuration of my friends
By: Matt Jordan (mjordan) 2012-08-29 09:47:16.879-0500

Can you attach a new DEBUG log with 'sip set debug on'?  If its a problem with directmedia, there's a good chance that something isn't being negotiated properly in the SIP requests.
By: Maciej Krajewski (jamicque) 2012-08-29 09:49:10.401-0500

sippeers_propper.txt is the proper sip configuration
By: Maciej Krajewski (jamicque) 2012-08-29 09:51:40.906-0500

I've attached the full debug + sip debug.
By: Maciej Krajewski (jamicque) 2012-08-30 15:27:19.412-0500

What I have also noticed on asterisk 1.8.13.1 (because on 1.8.15.0 directmedia does not work), the configuration parameters: "directmediapermit" and "directmediadeny" does not work, as they are not respected at all.
By: Maciej Krajewski (jamicque) 2012-09-03 09:28:22.061-0500

I've made some additional tests and if this is a hint, the configuration without realtime (only on configuration files) also does not work.
By: Maciej Krajewski (jamicque) 2012-09-04 07:33:38.336-0500

Is this information sufficient or should I attach some additional logs?
By: Matt Jordan (mjordan) 2012-09-06 08:54:15.648-0500

A few things.

{quote}
Configured peers has dtmfmode set to "info" (I know this is an issue that direct media ins not working if set to rfc2833 or inbound).
{quote}

I'm not sure what you're referring to that directmedia doesn't work if DTMF is set to RFC2833 or inbound.  directmedia still works fine, as does DTMF - its just that DTMF doesn't go through Asterisk, as the media has been directed between the peers.  So yes, if you want DTMF to still go through Asterisk, you have to use SIP INFO requests - but that isn't something "not working", that is something work exactly how you configured the system.

Anyway... :-)

directmediapermit/directmediadeny were changed in r366547 (in 1.8.14.0), as the behavior that they exhibited didn't really help users actually restrict directmedia setup between two peers.  Prior to the change, the address that was checked in a peer's ACL was the peer's own address - in the case of directmedia, this doesn't make much sense, as other ACLs already check the setup of that peer.  Instead, what should have been checked was the bridging peer's address to see if the peer should be able to send media to that peer.

Somehow that change didn't get mentioned in the UPGRADE file, which should have happened.  I'll get that fixed.

All of that aside, your configuration does not appear to be using those settings (although you referenced them in a comment) - so that's probably not the problem here.  I am having a bit of a tough time seeing where in the INVITE transactions things are getting out of whack - do you mind attaching a pcap?  Sometimes thats a lot clearer when all you need to see are the SIP messages.

Thanks!

By: Maciej Krajewski (jamicque) 2012-09-06 10:19:21.078-0500

Hi Matt,
I've mentioned the DTMF mode - because on asterisk 1.8.13.1 (the last version the directmedia was actually working) If I had dtmfmode any other than INFO the reinvite with direct IP a addresses in SDP was not sent.
Setting this to INFO made asterisk to send reinvite to both sides - maybe this also need to be checked?
I have found this info on this side (and this is actually true) - http://www.voip-info.org/wiki/view/Asterisk+sip+canreinvite

I will attach the cap file in a sec


By: Maciej Krajewski (jamicque) 2012-09-06 11:47:07.728-0500

I've attached the CAP file
By: Rusty Newton (rnewton) 2012-09-24 19:01:15.269-0500

Your capture was a bit confusing to me for several reasons, I'll have someone check it that has a bit more network-fu.

I've tested between two Digium D40 phones with SVN-branch-1.8-r373242.

Using a very basic configuration similar to the description -I found that depending on the dtmfmode option's value, media will or will not be externally bridged.

With directmedia=yes set for two endpoints local to Asterisk; here are the options I tested for dtmfmode and what the results of each test was for whether directmedia worked or not.

(directmedia and dtmfmode were set for both endpoints in sip.conf, tested on local LAN with no firewalling or NAT)

dtmfmode= (commented out or undefined): yes
dtmfmode=auto: yes
dtmfmode=inband: yes
dtmfmode=rfc2833: yes
dtmfmode=info: no
dtmfmode=shortinfo: no


To confirm, media did not flow directly between endpoints when either the info or shortinfo values were set for dtmfmode=. In those cases, media did flow through Asterisk perfectly. For any other dtmfmode value, media was setup directly between endpoints.

Maciej, does this sound as you would expect, or does it differ from your experience so far? I think this matches the behavior you described for the latest 1.8, but not for 1.8.13.1 correct?
By: Maciej Krajewski (jamicque) 2012-09-25 02:24:36.262-0500

Hi Rusty,
about the capture - it might be confusing because the capture was made on vserver were host is with interface bonding + vlans (in this case, tshark captures doubled or tripled incoming packets on interface). However form application side everything is ok (you can see it from asterisk logs with 'sip debug on').

Well, me experience with direct media is a little bit different - in 1.8.13.1 only dtmfmode=info worked fine (the rtp stream flew directly between phones). I've made test on yelink + cisco and also 2 softphones on the same computer and the behaviour was as I written earlier. Namely, on asterisk after 1.8.13.1 - directmedia stopped working at all. On asterisk 1.8.13.1 direcmedia worked only if dtmfmode=info.

On Asterisk 1.8.16 - directmedia still does not work.

By: Krzysztof Chmielewski (kristoff) 2012-09-25 08:03:18.169-0500

Hello,
in my test on 1.8.13.1 direct media worked fine despite dtmfmode, nevertheless on asterisk 1.8.16 witch the same configuration direct media does not work as said Maciej.
By: Rusty Newton (rnewton) 2012-09-25 11:31:24.100-0500

I just tested with SVN-branch-1.8-r373578 and directmedia works fine with any dtmfmode setting.

Can you re-test with SVN of 1.8 ? It appears this issue was fixed in ASTERISK-20409 at revision #373532


By: Maciej Krajewski (jamicque) 2012-09-26 03:10:59.909-0500

Hi I've tested the svn branch 1.8 revision 373578 and media is still flowing through asterisk.
By: Krzysztof Chmielewski (kristoff) 2012-09-26 05:41:22.063-0500

Hi I've tested the SVN-branch-1.8-r373773 and direct media is not working.
After downgrading to 1.8.13 version, everything works fine.

On SVN-branch-1.8-r373773, CLI output for sip show peer and sip show setting shows that Direct Media is on, but RTP is going through asterisk.
By: Rusty Newton (rnewton) 2012-09-26 09:42:53.720-0500

Krysztof, are you using realtime for your sip peers?

Maciej, are you using directmediapermit or deny? If so, can you test with those settings defaulted or undefined?  Do you also have an easy way to test this without a realtime setup, but using the same sip.conf options?
By: Maciej Krajewski (jamicque) 2012-09-26 10:02:01.171-0500

Hi Rusty,
tested on SVN-branch-1.8-r373578 - I've done all config in static (no real-time), directmedia=yes, directmediapermit and directmediadeny commented out (as in default configuration), media is still flowing through asterisk.

I've also tried to set directmediapermit to 0.0.0.0/0 however, it did not help.
By: Maciej Krajewski (jamicque) 2012-09-28 04:56:39.103-0500

I've attached the sip.conf from the not working directmedia.
By: Rusty Newton (rnewton) 2012-10-01 09:54:07.234-0500

Maciej, using the static configuration (not realtime) provide the output of "sip show peer <peer>" and "sip show user <user>" for both of the users and peers created by your type=friend entries. Also, while the call is up and running, (with media flowing through asterisk), can you provide the output of "sip show channel <channel>" for the relevant channel or channels?


By: Maciej Krajewski (jamicque) 2012-10-01 10:07:48.071-0500

test001
{code}sip show peer test001


 * Name       : test001
 Secret       : <Set>
 MD5Secret    : <Not set>
 Remote Secret: <Not set>
 Context      : asterisk
 Subscr.Cont. : asterisk
 Language     :
 AMA flags    : Unknown
 Transfer mode: open
 CallingPres  : Presentation Allowed, Not Screened
 Callgroup    :
 Pickupgroup  :
 MOH Suggest  :
 Mailbox      : 1234@default,1233@default
 VM Extension : asterisk
 LastMsgsSent : 0/0
 Call limit   : 0
 Max forwards : 0
 Dynamic      : Yes
 Callerid     : "Jane Smith" <5678>
 MaxCallBR    : 1024 kbps
 Expire       : 23
 Insecure     : no
 Force rport  : Yes
 ACL          : No
 DirectMedACL : No
 T.38 support : Yes
 T.38 EC mode : FEC
 T.38 MaxDtgrm: -1
 DirectMedia  : Yes
 PromiscRedir : No
 User=Phone   : No
 Video Support: Yes
 Text Support : No
 Ign SDP ver  : No
 Trust RPID   : No
 Send RPID    : No
 Subscriptions: Yes
 Overlap dial : Yes
 DTMFmode     : rfc2833
 Timer T1     : 500
 Timer B      : 32000
 ToHost       :
 Addr->IP     : 10.0.0.2:5060
 Defaddr->IP  : (null)
 Prim.Transp. : UDP
 Allowed.Trsp : UDP
 Def. Username: test001
 SIP Options  : (none)
 Codecs       : 0xe (gsm|ulaw|alaw)
 Codec Order  : (gsm:20,ulaw:20,alaw:20)
 Auto-Framing :  No
 Status       : Unmonitored
 Useragent    : Zoiper rev.11137
 Reg. Contact : sip:test001@10.0.0.2:5060;rinstance=838af85f46405011;transport=UDP
 Qualify Freq : 40000 ms
 Sess-Timers  : Accept
 Sess-Refresh : uas
 Sess-Expires : 1800 secs
 Min-Sess     : 90 secs
 RTP Engine   : asterisk
 Parkinglot   :
 Use Reason   : No
 Encryption   : No
{code}

test002
{code}
sip show peer test002


 * Name       : test002
 Secret       : <Set>
 MD5Secret    : <Not set>
 Remote Secret: <Not set>
 Context      : asterisk
 Subscr.Cont. : asterisk
 Language     :
 AMA flags    : Unknown
 Transfer mode: open
 CallingPres  : Presentation Allowed, Not Screened
 Callgroup    :
 Pickupgroup  :
 MOH Suggest  :
 Mailbox      : 1234@default,1233@default
 VM Extension : asterisk
 LastMsgsSent : 0/0
 Call limit   : 0
 Max forwards : 0
 Dynamic      : Yes
 Callerid     : "Jane Smith" <5678>
 MaxCallBR    : 1024 kbps
 Expire       : 55
 Insecure     : no
 Force rport  : Yes
 ACL          : No
 DirectMedACL : No
 T.38 support : Yes
 T.38 EC mode : FEC
 T.38 MaxDtgrm: -1
 DirectMedia  : Yes
 PromiscRedir : No
 User=Phone   : No
 Video Support: Yes
 Text Support : No
 Ign SDP ver  : No
 Trust RPID   : No
 Send RPID    : No
 Subscriptions: Yes
 Overlap dial : Yes
 DTMFmode     : rfc2833
 Timer T1     : 500
 Timer B      : 32000
 ToHost       :
 Addr->IP     : 172.16.0.84:5062
 Defaddr->IP  : (null)
 Prim.Transp. : UDP
 Allowed.Trsp : UDP
 Def. Username: test002
 SIP Options  : (none)
 Codecs       : 0xe (gsm|ulaw|alaw)
 Codec Order  : (gsm:20,ulaw:20,alaw:20)
 Auto-Framing :  No
 Status       : Unmonitored
 Useragent    : Linksys/SPA962-6.1.5(a)
 Reg. Contact : sip:test002@172.16.0.84:5062
 Qualify Freq : 40000 ms
 Sess-Timers  : Accept
 Sess-Refresh : uas
 Sess-Expires : 1800 secs
 Min-Sess     : 90 secs
 RTP Engine   : asterisk
 Parkinglot   :
 Use Reason   : No
 Encryption   : No
{code}


first channel
{code}
sip show channel 392ebbf11217952f067c18f44c0abd8f@10.0.4.63:5060

 * SIP Call
 Curr. trans. direction:  Outgoing
 Call-ID:                392ebbf11217952f067c18f44c0abd8f@10.0.4.63:5060
 Owner channel ID:       SIP/test002-00000005
 Our Codec Capability:   0xe (gsm|ulaw|alaw)
 Non-Codec Capability (DTMF):   1
 Their Codec Capability:   0x4 (ulaw)
 Joint Codec Capability:   0x4 (ulaw)
 Format:                 0x4 (ulaw)
 T.38 support            No
 Video support           No
 MaxCallBR:              1024 kbps
 Theoretical Address:    172.16.0.84:5062
 Received Address:       172.16.0.84:5062
 SIP Transfer mode:      open
 Force rport:            Yes
 Audio IP:               10.0.4.63 (local)
 Our Tag:                as1772de95
 Their Tag:              39f7c1126c2d0a2ei2
 SIP User agent:
 Username:               test002
 Peername:               test002
 Original uri:           sip:test002@172.16.0.84:5062
 Caller-ID:              5678
 Need Destroy:           No
 Last Message:           Tx: ACK
 Promiscuous Redir:      No
 Route:                  sip:test002@172.16.0.84:5062
 DTMF Mode:              rfc2833
 SIP Options:            (none)
 Session-Timer:          Inactive
{code}
and the second one
{code}
sip show channel ZDFmODRiZGIyYzg2MWJlM2IzZDczNGZkNmVjY2VlYzQ.

 * SIP Call
 Curr. trans. direction:  Incoming
 Call-ID:                ZDFmODRiZGIyYzg2MWJlM2IzZDczNGZkNmVjY2VlYzQ.
 Owner channel ID:       SIP/test001-00000004
 Our Codec Capability:   0xe (gsm|ulaw|alaw)
 Non-Codec Capability (DTMF):   1
 Their Codec Capability:   0x60c (ulaw|alaw|speex|ilbc)
 Joint Codec Capability:   0xc (ulaw|alaw)
 Format:                 0x4 (ulaw)
 T.38 support            No
 Video support           No
 MaxCallBR:              1024 kbps
 Theoretical Address:    10.0.0.2:5060
 Received Address:       10.0.0.2:5060
 SIP Transfer mode:      open
 Force rport:            Yes
 Audio IP:               10.0.4.63 (local)
 Our Tag:                as167300ab
 Their Tag:              802d1a03
 SIP User agent:         Zoiper rev.11137
 Username:               test001
 Peername:               test001
 Original uri:           sip:test001@10.0.0.2:5060
 Caller-ID:              5678
 Need Destroy:           No
 Last Message:           Rx: ACK
 Promiscuous Redir:      No
 Route:                  sip:test001@10.0.0.2:5060;transport=UDP
 DTMF Mode:              rfc2833
 SIP Options:            norefersub replaces replace
 Session-Timer:          Inactive

{code}
By: Rusty Newton (rnewton) 2012-10-02 11:17:21.051-0500

Maciej, for clarity, can you describe what physical device is at each of the IP addresses in the above output? (all IP addresses mentioned in the "sip show channel.." output)

If the information is sensitive, you can set restriction to Digium and Reporter only when commenting (see the lock icon).

By: Maciej Krajewski (jamicque) 2012-10-02 13:46:21.382-0500

Hi Rusty,
no problem, all of the addresses are in 24 bit network, different vlans connected to the same router.
10.0.4.63 is the address of asterisk let say VLAN A
10.0.0.2 is the address of the test001 user in VLAN B
172.16.0.84 is the address of the test002 user in VLAN C
I've tried placing test002 in VLAN B however id did not make any change.

About the restriction of traffic between those vlans - none. No nat, simply allow in both directions. Every endpoint see each other on their ip addresses, can ping each other etc.
By: Matt Jordan (mjordan) 2012-10-02 14:30:10.396-0500

I am completely unable to reproduce this problem using the latest from SVN 1.8.

Test Phone 1 (digium01):
{code}
[digium01]
type = friend
secret = digium01
directmedia = yes
callerid = "Digium 01" <101>
host = dynamic
disallow = all
allow = gsm
allow = ulaw
allow = alaw
allow = g722
context = from-digium-phones
registertrying = yes
{code}


Test Phone 2 (digium02):
{code}
[digium02]
type = friend
secret = digium02
directmedia = yes
callerid = "Digium 02" <102>
host = dynamic
disallow = all
allow = gsm
allow = ulaw
allow = alaw
allow = g722
context = from-digium-phones
registertrying = yes
{code}

Sample CLI:

{code}
[mjordan-desktop 1.8]$ asterisk -V
Asterisk SVN-branch-1.8-r374177
{code}

{code}
*CLI>   == Using SIP RTP CoS mark 5
   -- Executing [102@from-digium-phones:1] NoOp("SIP/digium01-00000000", "") in new stack
   -- Executing [102@from-digium-phones:2] Dial("SIP/digium01-00000000", "SIP/digium02") in new stack
 == Using SIP RTP CoS mark 5
   -- Called SIP/digium02
   -- SIP/digium02-00000001 is ringing
[Oct  2 14:26:57] NOTICE[25083]: chan_sip.c:25054 handle_request_subscribe: Received SIP subscribe for peer without mailbox: digium01
   -- SIP/digium02-00000001 answered SIP/digium01-00000000
   -- Remotely bridging SIP/digium01-00000000 and SIP/digium02-00000001
[Oct  2 14:27:01] NOTICE[25083]: chan_sip.c:25054 handle_request_subscribe: Received SIP subscribe for peer without mailbox: digium02
 == Spawn extension (from-digium-phones, 102, 2) exited non-zero on 'SIP/digium01-00000000'
{code}

Note that I used the peer configurations you provided in your sample sip.conf.  I'm not sure what the issue is, but without any further evidence of this issue persisting in Asterisk 1.8, I'm inclined to think it should be closed as "Can't Reproduce".
By: Maciej Krajewski (jamicque) 2012-10-02 14:35:45.551-0500

I'll try to test it on latest svn and let you know.
By: Maciej Krajewski (jamicque) 2012-10-02 15:30:10.141-0500

Rusty, Matt,
thank you for your help.
After Matt latest post the RTP media still did not work as it should. I revisioned my sip.conf, after commenting many options witch did not change anything. I have found the source of the problem... in my extensions.conf I had such a declaration:
{code}
[globals]
DYNAMIC_FEATURES=>rod
{code}

and this was it... after deleting it it has stared to work... Once again thank you very much for your help.
By: Matt Jordan (mjordan) 2012-10-02 15:34:03.644-0500

Yup, that would do it :-)

No problem - glad its working again!