[asterisk-dev] asterisk-dev Digest, Vol 47, Issue 17

Fredrik Hansson fh at leissner.se
Sat Apr 4 03:26:01 CDT 2009


Hi bilal,

Could this be what you are searching for.

rtptimeout = seconds : Terminate call if x seconds of no RTP activity
when we're not on hold. Valid only in [general] section and type=peer.


--FH



> -----Original Message-----
> From: asterisk-dev-bounces at lists.digium.com [mailto:asterisk-dev-
> bounces at lists.digium.com] On Behalf Of bilal ghayyad
> Sent: den 4 april 2009 00:59
> To: asterisk-dev at lists.digium.com
> Subject: Re: [asterisk-dev] asterisk-dev Digest, Vol 47, Issue 17
> 
> 
> Hi Raj;
> 
> Where is the below parameters can be found in the sip.conf? I did not
find
> them and my asterisk is 1.4.19.2:
> session-timers=originate
> session-expires=600
> session-minse=90
> session-refresher=uas
> 
> Also, I think in my case, maybe these parameters does not help me?
Because
> maybe I need something related to rtp, as we are talking about: how to
> disconnect the call if internet was disconnected, so the hangup has
not
> been detected?
> 
> Regards
> Bilal
> 
> 
> > On Wed, Jun 4, 2008 at 12:12 PM, bilal ghayyad
> > <bilmar_gh at yahoo.com> wrote:
> > > And in case of SIP, I heared it is existed but I have
> > > to check the session timer in the trunk version of the
> > > sip_chan, but really I do not know how to check this
> > > and wether there is any need to be done on the source
> > > to be modified and compiled to obtain it successfully
> > > working.
> >
> > There is no need to modify/compile the source code for
> > this.
> > Session-timers are configured in sip.conf. There are four
> > flags that
> > control the operation of this feature:
> >
> > session-timers=originate
> > session-expires=600
> > session-minse=90
> > session-refresher=uas
> >
> > You can either set them globally or at a per user/peer
> > level. The
> > value of "originate" for session-timers flag
> > means that Asterisk will
> > actively request session-timers support from the other
> > end-point. If
> > the other end-point supports session-timers then the two
> > will
> > negotiate the frequency at which session will be refreshed
> > and which
> > side will initiate the refresh requests. In the
> > "originate" mode even
> > if the other end-point doesn't support this feature,
> > Asterisk will
> > refresh the session periodically anyway.
> >
> > The session-expires and session-mine are high and low
> > watermarks for
> > how tolerable Asterisk will be to the frequency of session
> > refreshes.
> > Feel free to tune these to what's more suitable in your
> > environment.
> >
> > --
> > Raj Jain
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Wed, 04 Jun 2008 12:54:23 -0500
> > From: Russell Bryant <russell at digium.com>
> > Subject: Re: [asterisk-dev] [policy] Discussion on IRC -
> > how to make
> > 	-dev more useful
> > To: Asterisk Developers Mailing List
> > <asterisk-dev at lists.digium.com>
> > Message-ID: <4846D6CF.7040501 at digium.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Tilghman Lesher wrote:
> > > On Wednesday 04 June 2008 09:53:36 Matthew Fredrickson
> > wrote:
> > >> Not to be Mr. Negativity here, but I concur as
> > well.  Asterisk-dev is
> > >> not a high traffic list at all (LKML is a great
> > example of a high
> > >> traffic list), and any solution that puts the load
> > on the posters is
> > >> going to have major trouble gaining traction.
> > >
> > > People who don't want to call extra attention to
> > their proposals are free
> > > to ignore it.  Those of us who _want_ to draw
> > attention and discussion from
> > > the list will use the tags.  Quite simple, really.  I
> > think I've already used
> > > the [policy] tag once before, and it's nice to
> > have a formal proposal, so that
> > > we all know what the various tags mean.
> >
> > I agree with Tilghman.
> >
> > I don't think these tags should be a requirement, but I
> > think they are a
> > welcome addition to common practice for this list.  If a
> > poster doesn't
> > want to use them, fine, it doesn't really matter.
> > However, having more
> > clearly defined subjects certainly isn't going to hurt
> > anything.
> >
> > --
> > Russell Bryant
> > Senior Software Engineer
> > Open Source Team Lead
> > Digium, Inc.
> >
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Wed, 04 Jun 2008 13:50:28 -0500
> > From: Matthew Fredrickson <creslin at digium.com>
> > Subject: Re: [asterisk-dev] [policy] Discussion on IRC -
> > how to make
> > 	-dev more useful
> > To: Asterisk Developers Mailing List
> > <asterisk-dev at lists.digium.com>
> > Message-ID: <4846E3F4.8050605 at digium.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Russell Bryant wrote:
> > > Tilghman Lesher wrote:
> > >> On Wednesday 04 June 2008 09:53:36 Matthew
> > Fredrickson wrote:
> > >>> Not to be Mr. Negativity here, but I concur as
> > well.  Asterisk-dev is
> > >>> not a high traffic list at all (LKML is a
> > great example of a high
> > >>> traffic list), and any solution that puts the
> > load on the posters is
> > >>> going to have major trouble gaining traction.
> > >> People who don't want to call extra attention
> > to their proposals are free
> > >> to ignore it.  Those of us who _want_ to draw
> > attention and discussion from
> > >> the list will use the tags.  Quite simple, really.
> >  I think I've already used
> > >> the [policy] tag once before, and it's nice to
> > have a formal proposal, so that
> > >> we all know what the various tags mean.
> > >
> > > I agree with Tilghman.
> > >
> > > I don't think these tags should be a requirement,
> > but I think they are a
> > > welcome addition to common practice for this list.  If
> > a poster doesn't
> > > want to use them, fine, it doesn't really matter.
> > However, having more
> > > clearly defined subjects certainly isn't going to
> > hurt anything.
> >
> > As long as we don't set a policy that makes
> > communication more
> > difficult, I have no problems with it.  So as long as it is
> > not a
> > requirement, that sounds pretty reasonable.
> >
> > --
> > Matthew Fredrickson
> > Software/Firmware Engineer
> > Digium, Inc.
> >
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Wed, 4 Jun 2008 14:37:59 -0500
> > From: Tilghman Lesher
> > <tilghman at mail.jeffandtilghman.com>
> > Subject: Re: [asterisk-dev] [policy] Discussion on IRC -
> > how to make
> > 	-dev more useful
> > To: Asterisk Developers Mailing List
> > <asterisk-dev at lists.digium.com>
> > Message-ID:
> > <200806041437.59924.tilghman at mail.jeffandtilghman.com>
> > Content-Type: text/plain;  charset="iso-8859-1"
> >
> > On Wednesday 04 June 2008 10:45:27 Jay R. Ashworth wrote:
> > > On Wed, Jun 04, 2008 at 10:26:48AM -0500, Tilghman
> > Lesher wrote:
> > > > People who don't want to call extra attention
> > to their proposals are free
> > > > to ignore it.  Those of us who _want_ to draw
> > attention and discussion
> > > > from the list will use the tags.  Quite simple,
> > really.  I think I've
> > > > already used the [policy] tag once before, and
> > it's nice to have a formal
> > > > proposal, so that we all know what the various
> > tags mean.
> > >
> > > And people who want to join in your
> > >
> > > 1452 N * 06/04 Tilghman Lesher (  51) Re:
> > [asterisk-dev] [policy]
> > > Discussion on
> > >
> > > oh, wait.  Discussion on *what*?  Bummer.  :-)
> >
> > Without the tag, the remainder of the subject would have
> > been
> > "Discussion on IRC - how to", which still
> > doesn't give you any more
> > information.  The real key is probably that you need to
> > widen your
> > terminal, which I do believe Mutt will take advantage of to
> > display
> > more characters in the subject.
> >
> > --
> > Tilghman
> >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Wed, 4 Jun 2008 20:51:14 +0100
> > From: Tim Panton <thp at westhawk.co.uk>
> > Subject: Re: [asterisk-dev] Media TimeOut for SIP and IAX
> > Trunk
> > To: Asterisk Developers Mailing List
> > <asterisk-dev at lists.digium.com>
> > Message-ID:
> > <6DDBCB55-DDA2-454C-9167-6EE53155E34A at westhawk.co.uk>
> > Content-Type: text/plain; charset=US-ASCII; format=flowed
> >
> >
> > On 4 Jun 2008, at 17:12, bilal ghayyad wrote:
> >
> > > Hi List;
> > >
> > > Any one can advise me if IAX trunk support media time
> > > out to disconnec the call automatically after certain
> > > vaule of timeout in case no more media running between
> > > end points and hangup signal was not available (which
> > > happens in alot of cases)?
> > >
> > > And in case of SIP, I heared it is existed but I have
> > > to check the session timer in the trunk version of the
> > > sip_chan, but really I do not know how to check this
> > > and wether there is any need to be done on the source
> > > to be modified and compiled to obtain it successfully
> > > working.
> > >
> > > Any help?
> > >
> >
> > Isn't this is the default behavior in IAX2? Normally
> > IAX
> > doesn't separate the media from the control, so
> > generally
> > IAX will drop a call a few seconds after the last received
> > packet.
> >
> >
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Wed, 4 Jun 2008 16:00:05 -0400
> > From: "Jay R. Ashworth" <jra at baylink.com>
> > Subject: Re: [asterisk-dev] [policy] Discussion on IRC -
> > how to make
> > 	-dev	more useful
> > To: asterisk-dev at lists.digium.com
> > Message-ID: <20080604200005.GB674 at cgi.jachomes.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Wed, Jun 04, 2008 at 02:37:59PM -0500, Tilghman Lesher
> > wrote:
> > > On Wednesday 04 June 2008 10:45:27 Jay R. Ashworth
> > wrote:
> > > > On Wed, Jun 04, 2008 at 10:26:48AM -0500,
> > Tilghman Lesher wrote:
> > > > > People who don't want to call extra
> > attention to their proposals are free
> > > > > to ignore it.  Those of us who _want_ to
> > draw attention and discussion
> > > > > from the list will use the tags.  Quite
> > simple, really.  I think I've
> > > > > already used the [policy] tag once before,
> > and it's nice to have a formal
> > > > > proposal, so that we all know what the
> > various tags mean.
> > > >
> > > > And people who want to join in your
> > > >
> > > > 1452 N * 06/04 Tilghman Lesher (  51) Re:
> > [asterisk-dev] [policy]
> > > > Discussion on
> > > >
> > > > oh, wait.  Discussion on *what*?  Bummer.  :-)
> > >
> > > Without the tag, the remainder of the subject would
> > have been
> > > "Discussion on IRC - how to", which still
> > doesn't give you any more
> > > information.
> >
> > Yes, but *that* isn't the fault of the tagging policy.
> > It's the fault
> > of the original poster.
> >
> > >               The real key is probably that you need
> > to widen your
> > > terminal, which I do believe Mutt will take advantage
> > of to display
> > > more characters in the subject.
> >
> > I'm old.  :-)  I have to keep the xterm windows
> > comfortably readable
> > because I stare at them all day.  And, ironically, I have
> > another
> > problem, which perhaps someone knows the answer to:  If you
> > *do* run
> > mutt in an xterm wider than 80 characters, I have not yet
> > found a
> > reliable way to get *vi* (vim, actually) to autowrap based
> > on the
> > *left* margin rather than the right one, as is its default.
> >  This
> > leaves you needing to reset your wm every time you resize
> > the window,
> > which is similarly unpleasant.
> >
> > Suggestions?  Did I miss, say, the ability to
> >
> > set wm=-72
> >
> > ?
> >
> > Cheers,
> > -- jra
> > --
> > Jay R. Ashworth                   Baylink
> >    jra at baylink.com
> > Designer                     The Things I Think
> >           RFC 2100
> > Ashworth & Associates     http://baylink.pitas.com
> >                '87 e24
> > St Petersburg FL USA      http://photo.imageinc.us
> >    +1 727 647 1274
> >
> > 	     Those who cast the vote decide nothing.
> > 	     Those who count the vote decide everything.
> > 	       -- (Joseph Stalin)
> >
> >
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Wed, 04 Jun 2008 15:09:13 -0500
> > From: Mark Michelson <mmichelson at digium.com>
> > Subject: Re: [asterisk-dev] [other] Reliability of TRANSFER
> > event in
> > 	queue_log
> > To: Asterisk Developers Mailing List
> > <asterisk-dev at lists.digium.com>
> > Message-ID: <4846F669.8000800 at digium.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Sa?l Ibarra wrote:
> > > Hi all:
> > >
> > > I'm about to precess some queue events, and by
> > reading the
> > > documentation I found the event TRANSFER isn't
> > reliable with native
> > > sip transfers. Is this still true? Is there any
> > workaround without
> > > using asterisk transfers? Thanks in advance.
> > >
> >
> > When you say "queue events" I assume you mean
> > lines in the queue_log file. The
> > TRANSFER event will only show up in the queue_log on a
> > blind transfer. This can
> > be done either with a native SIP transfer or with
> > Asterisk's internal blind
> > transfer mechanism. Attended transfers, no matter how they
> > are initiated, will
> > not show up in the queue_log.
> >
> > Mark Michelson
> >
> >
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Wed, 4 Jun 2008 16:10:22 -0400
> > From: "Jay R. Ashworth" <jra at baylink.com>
> > Subject: Re: [asterisk-dev] [policy] Discussion on IRC -
> > how to make
> > 	-dev	more useful
> > To: asterisk-dev at lists.digium.com
> > Message-ID: <20080604201022.GC674 at cgi.jachomes.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Wed, Jun 04, 2008 at 04:00:05PM -0400, Jay R. Ashworth
> > wrote:
> > > I'm old.  :-)  I have to keep the xterm windows
> > comfortably readable
> > > because I stare at them all day.  And, ironically, I
> > have another
> > > problem, which perhaps someone knows the answer to:
> > If you *do* run
> > > mutt in an xterm wider than 80 characters, I have not
> > yet found a
> > > reliable way to get *vi* (vim, actually) to autowrap
> > based on the
> > > *left* margin rather than the right one, as is its
> > default.  This
> > > leaves you needing to reset your wm every time you
> > resize the window,
> > > which is similarly unpleasant.
> > >
> > > Suggestions?  Did I miss, say, the ability to
> > >
> > > set wm=-72
> > >
> > > ?
> >
> > I did: it's called "textwidth", and it
> > figures from the left.  Thanks,
> > Tilghman, for prompting me to go look it up.
> >
> > Cheers,
> > -- jra
> > --
> > Jay R. Ashworth                   Baylink
> >    jra at baylink.com
> > Designer                     The Things I Think
> >           RFC 2100
> > Ashworth & Associates     http://baylink.pitas.com
> >                '87 e24
> > St Petersburg FL USA      http://photo.imageinc.us
> >    +1 727 647 1274
> >
> > 	     Those who cast the vote decide nothing.
> > 	     Those who count the vote decide everything.
> > 	       -- (Joseph Stalin)
> >
> >
> >
> > ------------------------------
> >
> > Message: 9
> > Date: Thu, 05 Jun 2008 09:10:56 +1200
> > From: Nic Bellamy <nicb-lists at vadacom.co.nz>
> > Subject: Re: [asterisk-dev] Another IAX2 problem with the
> > latest
> > 	security fix ...
> > To: Asterisk Developers Mailing List
> > <asterisk-dev at lists.digium.com>
> > Message-ID: <484704E0.2010100 at vadacom.co.nz>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Russell Bryant wrote:
> > > Tim Panton wrote:
> > >
> > >> It makes no sense to have a LAGRQ packet without a
> > call set up .
> > >> Arguably it makes no sense to have a PING without
> > a call.
> > >>
> > >> For what it is worth, I think it would be better
> > to
> > >> implement the initial 'hack' i.e.
> > don't send LAGRQ  or  PING
> > >> untill the call is set up.
> > >> Then add an additional hack where these two
> > don't have their
> > >> call numbers checked for backwards compatibility.
> > >>
> > >
> > > Agreed.  So, we'll go with my original hack, plus
> > your proposed hack #2 which
> > > will maintain backwards compatibility, without
> > introducing any unsafe behavior.
> > >
> >
> > Hi Russell,
> >     just a bit of feedback on this fix, which ended up in
> > 1.2.29 -
> > firstly, I've been running 1.2.29 for about 24 hours
> > now, and haven't
> > had any VNAK/INVAL floods, so I think we can consider that
> > solved.
> >
> > The only oddity I've noticed is that a large proportion
> > of the peers
> > with qualify=yes go LAGGED for a short period after an
> > "iax2 reload",
> > with lag figures of 2000ms + nominal latency. Not exactly
> > critical (at
> > least not to me), but perhaps related to the PING/LAGRQ
> > changes.
> >
> > Cheers,
> >     Nic.
> >
> > --
> > Nic Bellamy,
> > Head Of Engineering, Vadacom Ltd -
> > http://www.vadacom.co.nz/
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 10
> > Date: Wed, 4 Jun 2008 21:44:35 +0000 (UTC)
> > From: tony at softins.clara.co.uk (Tony Mountifield)
> > Subject: Re: [asterisk-dev] mmichelson: branch 1.2 r620 -
> > in
> > 	/branches/1.2/asterisk-ooh323c: ooh323c/src/...
> > To: asterisk-dev at lists.digium.com
> > Message-ID: <g272c3$ff6$1 at softins.clara.co.uk>
> >
> > In article <E1K3wHH-0005CF-Lm at lists.digium.com>,
> > SVN commits to the Digium repositories
> > <svn-commits at lists.digium.com> wrote:
> > > Author: mmichelson
> > > Date: Wed Jun  4 11:55:58 2008
> > > New Revision: 620
> > >
> > > URL:
> > http://svn.digium.com/view/asterisk-addons?view=rev&rev=620
> > > Log:
> > > A few changes:
> > >
> > > [...]
> > > 2. (1.2 only) There was a char * being used before
> > being set. This was causing an almost
> > >    immediate crash when ooh323 would load. This commit
> > fixes that issue.
> >
> > Please see below...
> >
> > > [...]
> > > Modified:
> > branches/1.2/asterisk-ooh323c/src/chan_h323.c
> > > URL:
> > >
> > http://svn.digium.com/view/asterisk-addons/branches/1.2/asterisk-
> ooh323c/src/chan_h323.c?view=diff&rev=620&r1=619&r2=620
> > >
> >
>
========================================================================
==
> ====
> > > --- branches/1.2/asterisk-ooh323c/src/chan_h323.c
> > (original)
> > > +++ branches/1.2/asterisk-ooh323c/src/chan_h323.c Wed
> > Jun  4 11:55:58 2008
> > > @@ -1887,8 +1887,12 @@
> > >     ooconfig.mTCPPortStart = 12030;
> > >     ooconfig.mTCPPortEnd = 12230;
> > >
> > > +   ast_log(LOG_NOTICE, "Check 1\n");
> > > +
> > >     v = ast_variable_browse(cfg, "general");
> > >     while(v) {
> > > +
> > > +	   ast_log(LOG_NOTICE, "v is %s\n",
> > v->name);
> > >
> > >        if (!strcasecmp(v->name, "port"))
> > {
> > >           gPort = (int)strtol(v->value, NULL, 10);
> > > @@ -2046,6 +2050,7 @@
> > >           ast_parse_allow_disallow(&gPrefs,
> > &gCapability, tcodecs, 1);
> > >        }
> > >        else if (!strcasecmp(v->name,
> > "dtmfmode")) {
> > > +		  ast_log(LOG_NOTICE, "v's value is
> > %s\n", v->value);
> > >           if (!strcasecmp(v->value,
> > "inband"))
> > >              gDTMFMode=H323_DTMF_INBAND;
> > >           else if (!strcasecmp(v->value,
> > "rfc2833"))
> >
> > Are the above changes left-over debugging statements?
> >
> > > @@ -2070,8 +2075,9 @@
> > >     {
> > >        if(strcasecmp(cat, "general"))
> > >        {
> > > -         int friend_type = strcasecmp(utype,
> > "friend");
> > > +         int friend_type;
> > >           utype = ast_variable_retrieve(cfg, cat,
> > "type");
> > > +		 friend_type = strcasecmp(utype,
> > "friend");
> > >           if(utype)
> > >           {
> > >              if(!strcmp(utype, "user") || 0
> > == friend_type)
> >
> > It's good to see this bug fixed in 1.2, as I also found
> > it myself recently,
> > but the strcasecmp with utype should really go inside the
> > if(utype){ },
> > else a missing type= line would still crash Asterisk.
> >
> > 1.4 and later are already correct in this respect.
> >
> > Cheers
> > Tony
> > --
> > Tony Mountifield
> > Work: tony at softins.co.uk - http://www.softins.co.uk
> > Play: tony at mountifield.org - http://tony.mountifield.org
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > --Bandwidth and Colocation Provided by
> > http://www.api-digital.com--
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >    http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> > End of asterisk-dev Digest, Vol 47, Issue 17
> > ********************************************
> 
> 
> 
> 
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev



More information about the asterisk-dev mailing list