Summary: | ASTERISK-20333: 'directmedia' not working any more | ||||
Reporter: | Maciej Krajewski (jamicque) | Labels: | |||
Date Opened: | 2012-08-29 08:28:42 | Date Closed: | 2012-10-02 15:30:10 | ||
Priority: | Major | Regression? | Yes | ||
Status: | Closed/Complete | Components: | Channels/chan_sip/General | ||
Versions: | 1.8.15.0 | Frequency of Occurrence | Constant | ||
Related Issues: |
| ||||
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! |