[Home]

Summary:ASTERISK-14754: [patch][regression] LIMIT_TIMEOUT_FILE is not functional
Reporter:adomjan (adomjan)Labels:
Date Opened:2009-09-02 07:42:11Date Closed:2010-03-23 16:20:59
Priority:MinorRegression?Yes
Status:Closed/CompleteComponents:Core/Channels
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20090902__issue15815.diff.txt
Description:I run similar functional bug in 1.6.0.9 but it was fixed there, but in 1.6.0.14 exists, however the fix in 1.6.0.9 is included in 1.6.0.14.

 -- Executing [01231@sip:1] Set("SIP/11-b7f08060", "LIMIT_PLAYAUDIO_CALLER=yes") in new stack
   -- Executing [01231@sip:2] Set("SIP/11-b7f08060", "LIMIT_PLAYAUDIO_CALLEE=no") in new stack
   -- Executing [01231@sip:3] Set("SIP/11-b7f08060", "LIMIT_TIMEOUT_FILE=x") in new stack
   -- Executing [01231@sip:4] Set("SIP/11-b7f08060", "LIMIT_CONNECT_FILE=x") in new stack
   -- Executing [01231@sip:5] Set("SIP/11-b7f08060", "LIMIT_WARNING_FILE=x") in new stack
   -- Executing [01231@sip:6] Dial("SIP/11-b7f08060", "SIP/sipteszt/1231,90,L(15000:5000)") in new stack
   -- Limit Data for this call:
      > timelimit      = 15000
      > play_warning   = 5000
      > play_to_caller = yes
      > play_to_callee = no
      > warning_freq   = 0
      > start_sound    = x
      > warning_sound  = x
      > end_sound      = x
 == Using SIP RTP CoS mark 5
   -- Called sipteszt/1231
   -- SIP/sipteszt-092627d0 answered SIP/11-b7f08060
   -- <SIP/11-b7f08060> Playing 'x.alaw' (language 'en')
   -- Packet2Packet bridging SIP/11-b7f08060 and SIP/sipteszt-092627d0
   -- Packet2Packet bridging SIP/11-b7f08060 and SIP/sipteszt-092627d0
// asterisk should play x file now, but it does not
   -- Packet2Packet bridging SIP/11-b7f08060 and SIP/sipteszt-092627d0
   -- <SIP/11-b7f08060> Playing 'x.alaw' (language 'en')
 == Spawn extension (sip, 01231, 6) exited non-zero on 'SIP/11-b7f08060'
Comments:By: Leif Madsen (lmadsen) 2009-09-02 08:15:18

Just verifying a couple of things:

* x.alaw does exist?
* it exists in /var/lib/asterisk/sounds/en/ ?

I seem to see the x.alaw trying to play -- I don't understand which part isn't working. I presume the other LIMIT_* files you've setup are working, but not that one in particular. It would probably be easier to see if you used different file names.

Assigned to Tilghman for now to review.
By: adomjan (adomjan) 2009-09-02 08:23:38

x exists, * playes the start_sound, playes the end_sound, but not the warning sounds, all of the files are the same.
Please examine output of the dialplan execution...

When * should play the warning_sound, returning from the Packet2Packet bridge, do nothing - and going back to the Packet2Packet bridge.
By: adomjan (adomjan) 2009-09-10 02:39:47

applied the patch, still does not work...

If I'm not using Packet2Packet neither Native bridging, it is ok:
(different dtmf mode on sip)

-- Executing [01231@sip:6] Dial("SIP/11-b7e10788", "SIP/sipteszt/1231,90,L(15000:5000)") in new stack
   -- Limit Data for this call:
      > timelimit      = 15000
      > play_warning   = 5000
      > play_to_caller = yes
      > play_to_callee = no
      > warning_freq   = 0
      > start_sound    = x
      > warning_sound  = x
      > end_sound      = x
 == Using SIP RTP CoS mark 5
   -- Called sipteszt/1231
   -- SIP/sipteszt-b7e1ece8 answered SIP/11-b7e10788
   -- <SIP/11-b7e10788> Playing 'x.alaw' (language 'en')
   -- <SIP/11-b7e10788> Playing 'x.alaw' (language 'en')
   -- <SIP/11-b7e10788> Playing 'x.alaw' (language 'en')
 == Spawn extension (sip, 01231, 6) exited non-zero on 'SIP/11-b7e10788'

Native bridging:
  -- Executing [01231@sip:6] Dial("SIP/11-b7e04318", "SIP/sipteszt/1231,90,L(15000:5000)") in new stack
   -- Limit Data for this call:
      > timelimit      = 15000
      > play_warning   = 5000
      > play_to_caller = yes
      > play_to_callee = no
      > warning_freq   = 0
      > start_sound    = x
      > warning_sound  = x
      > end_sound      = x
 == Using SIP RTP CoS mark 5
   -- Called sipteszt/1231
   -- SIP/sipteszt-b7e1c2e8 answered SIP/11-b7e04318
   -- <SIP/11-b7e04318> Playing 'x.alaw' (language 'en')
   -- Native bridging SIP/11-b7e04318 and SIP/sipteszt-b7e1c2e8
   -- Native bridging SIP/11-b7e04318 and SIP/sipteszt-b7e1c2e8
   -- Native bridging SIP/11-b7e04318 and SIP/sipteszt-b7e1c2e8
   -- <SIP/11-b7e04318> Playing 'x.alaw' (language 'en')
 == Spawn extension (sip, 01231, 6) exited non-zero on 'SIP/11-b7e04318'

Packet2Packet bridging:
 -- Executing [01231@sip:6] Dial("SIP/11-b7e04318", "SIP/sipteszt/1231,90,L(15000:5000)") in new stack
   -- Limit Data for this call:
      > timelimit      = 15000
      > play_warning   = 5000
      > play_to_caller = yes
      > play_to_callee = no
      > warning_freq   = 0
      > start_sound    = x
      > warning_sound  = x
      > end_sound      = x
 == Using SIP RTP CoS mark 5
   -- Called sipteszt/1231
   -- SIP/sipteszt-b7e1c2e8 answered SIP/11-b7e04318
   -- <SIP/11-b7e04318> Playing 'x.alaw' (language 'en')
   -- Packet2Packet bridging SIP/11-b7e04318 and SIP/sipteszt-b7e1c2e8
   -- Packet2Packet bridging SIP/11-b7e04318 and SIP/sipteszt-b7e1c2e8
   -- Packet2Packet bridging SIP/11-b7e04318 and SIP/sipteszt-b7e1c2e8
   -- <SIP/11-b7e04318> Playing 'x.alaw' (language 'en')
 == Spawn extension (sip, 01231, 6) exited non-zero on 'SIP/11-b7e04318'
By: Leif Madsen (lmadsen) 2009-09-10 07:17:25

What are the different DTMF modes that cause you to get Native and Packet2Packet bridging? I'd like to try and reproduce this, but since I have a limited setup, I'd like to know exactly what you're doing to change between these two modes.
By: adomjan (adomjan) 2009-09-10 07:24:23

To avoid using Native and Packet2Packet bridging I set for sipteszt dtmfmode=rfc2833 and for 11 dtmfmode=info, so rtp won't try Native and Packet2Packet bridging.
When I set rfc2833 and canreinvite=yes on both sipfriends asterisk will use Nativ bridging. When I set rfc2833 and canreinvite=no on both sipfriends asterisk will us Packet2Packet bridging.
By: Leif Madsen (lmadsen) 2010-01-13 13:37:40.000-0600

Just curious if this is still an issue? I haven't had a chance to reproduce, so before I go any further I'd like to know if the reporter is still having this issue. I had used this same functionality recently with luck, but perhaps I was not using the specific scenario as you described. Thanks!
By: adomjan (adomjan) 2010-01-14 09:46:09.000-0600

I will fetch the 1.6.0 svn into a test envinroment and I will test is again, tomorrow.
By: adomjan (adomjan) 2010-01-15 03:43:31.000-0600

Hi,
it is still not working....

SVN-branch-1.6.0-r240278
By: Leif Madsen (lmadsen) 2010-01-19 16:42:38.000-0600

Aha! Yep, I was able to reproduce this today! Without the Packet2Packet bridging, it worked fine. Below is the non-working version.

   -- Called 0004f2040002
   -- SIP/0004f2040002-00000007 is ringing
   -- SIP/0004f2040002-00000007 answered SIP/0004f2040001-00000006
   -- <SIP/0004f2040001-00000006> Playing 'beep.ulaw' (language 'en')
   -- Packet2Packet bridging SIP/0004f2040001-00000006 and SIP/0004f2040002-00000007
   -- Packet2Packet bridging SIP/0004f2040001-00000006 and SIP/0004f2040002-00000007

** BEEP SHOULD BE HERE **

   -- Packet2Packet bridging SIP/0004f2040001-00000006 and SIP/0004f2040002-00000007
   -- <SIP/0004f2040001-00000006> Playing 'beep.ulaw' (language 'en')
 == Spawn extension (phones, 666, 7) exited non-zero on 'SIP/0004f2040001-00000006'
By: Jeff Peeler (jpeeler) 2010-03-22 10:59:15

adomjan: Have you ever had this scenario work correctly for native bridging? I tested 1.6.0.9 and it also seems to have the problem. It would be helpful to know if this actually is a regression or not.
By: adomjan (adomjan) 2010-03-22 11:23:55

I don't remember, have to test, because I have Packet2Packet bridging (nat etc...)...
By: Digium Subversion (svnbot) 2010-03-23 16:17:24

Repository: asterisk
Revision: 254050

U   trunk/main/channel.c

------------------------------------------------------------------------
r254050 | jpeeler | 2010-03-23 16:17:24 -0500 (Tue, 23 Mar 2010) | 14 lines

Exit native bridging early for greater timing accuracy with warnings

This changes native bridging to break one millisecond early so that the more
accurate timeval calculations done in the generic bridge can be performed using
the bridge config. Currently the time between exiting native bridging slightly
late can sometimes cause a large enough discrepancy for warnings to be missed.
For the record, 1.4 does not attempt to native bridge at all when warnings are
enabled.

(closes issue ASTERISK-14754)
Reported by: adomjan

Review: https://reviewboard.asterisk.org/r/577/

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=254050
By: Digium Subversion (svnbot) 2010-03-23 16:19:46

Repository: asterisk
Revision: 254061

_U  branches/1.6.0/
U   branches/1.6.0/main/channel.c

------------------------------------------------------------------------
r254061 | jpeeler | 2010-03-23 16:19:46 -0500 (Tue, 23 Mar 2010) | 21 lines

Merged revisions 254050 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r254050 | jpeeler | 2010-03-23 16:17:23 -0500 (Tue, 23 Mar 2010) | 14 lines
 
 Exit native bridging early for greater timing accuracy with warnings
 
 This changes native bridging to break one millisecond early so that the more
 accurate timeval calculations done in the generic bridge can be performed using
 the bridge config. Currently the time between exiting native bridging slightly
 late can sometimes cause a large enough discrepancy for warnings to be missed.
 For the record, 1.4 does not attempt to native bridge at all when warnings are
 enabled.
 
 (closes issue ASTERISK-14754)
 Reported by: adomjan
 
 Review: https://reviewboard.asterisk.org/r/577/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=254061
By: Digium Subversion (svnbot) 2010-03-23 16:20:23

Repository: asterisk
Revision: 254065

_U  branches/1.6.1/
U   branches/1.6.1/main/channel.c

------------------------------------------------------------------------
r254065 | jpeeler | 2010-03-23 16:20:23 -0500 (Tue, 23 Mar 2010) | 21 lines

Merged revisions 254050 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r254050 | jpeeler | 2010-03-23 16:17:23 -0500 (Tue, 23 Mar 2010) | 14 lines
 
 Exit native bridging early for greater timing accuracy with warnings
 
 This changes native bridging to break one millisecond early so that the more
 accurate timeval calculations done in the generic bridge can be performed using
 the bridge config. Currently the time between exiting native bridging slightly
 late can sometimes cause a large enough discrepancy for warnings to be missed.
 For the record, 1.4 does not attempt to native bridge at all when warnings are
 enabled.
 
 (closes issue ASTERISK-14754)
 Reported by: adomjan
 
 Review: https://reviewboard.asterisk.org/r/577/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=254065
By: Digium Subversion (svnbot) 2010-03-23 16:20:58

Repository: asterisk
Revision: 254068

_U  branches/1.6.2/
U   branches/1.6.2/main/channel.c

------------------------------------------------------------------------
r254068 | jpeeler | 2010-03-23 16:20:58 -0500 (Tue, 23 Mar 2010) | 21 lines

Merged revisions 254050 via svnmerge from
https://origsvn.digium.com/svn/asterisk/trunk

........
 r254050 | jpeeler | 2010-03-23 16:17:23 -0500 (Tue, 23 Mar 2010) | 14 lines
 
 Exit native bridging early for greater timing accuracy with warnings
 
 This changes native bridging to break one millisecond early so that the more
 accurate timeval calculations done in the generic bridge can be performed using
 the bridge config. Currently the time between exiting native bridging slightly
 late can sometimes cause a large enough discrepancy for warnings to be missed.
 For the record, 1.4 does not attempt to native bridge at all when warnings are
 enabled.
 
 (closes issue ASTERISK-14754)
 Reported by: adomjan
 
 Review: https://reviewboard.asterisk.org/r/577/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=254068