[asterisk-dev] Re: asterisk-dev Digest, Vol 25, Issue 48

Sun Aug 20 20:55:39 MST 2006

hello everybody

This is regarding the interfacing of ASTERISK WITH C or  PHP.  As I
have gone through ur mail
I think u want to know how to put the php or c files in the dial plan.
For this:-

]]first read the AGI function 9also the dead agi ) this function is
responsible for executing the php or perl script program in the
dialplan
]] write the php program and save it in the  /var/lib/asterisk/agi-bin
]] put the extension xxxx,1,AGI(php-file name)

on receiving the xxxx string asterisk will execute the php file .ALSO
ther is lot u can do using this

ALSO I am reading for the fault tolerant ability of the asterisk and
from the net  I have got the little idia about the same. Now  trying
to integrate the OPENAIS with asterisk .

IS ther anyone to help me .

waiting for reply

THANKs and REGARDS
ramank

On 17/08/06, rajesh singh <prince_iter at yahoo.co.in> wrote:
> Sir
>
>     i am new to asterisk can you tell me how to interfACE ASTERISK WITH C or
> PHP to maintain a call in asterisk
>
>   thanks for mailing me
>
>   waiting for ur reply
>
>   punit kandoi
>
>
> asterisk-dev-request at lists.digium.com wrote:
>   Send asterisk-dev mailing list submissions to
> asterisk-dev at lists.digium.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> or, via email, send a message with subject or body 'help' to
> asterisk-dev-request at lists.digium.com
>
> You can reach the person managing the list at
> asterisk-dev-owner at lists.digium.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of asterisk-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Qualify OPTIONS messages (Evan Borgstr?m)
> 2. Zaptel Drivers----Thanks
> (Tim Johnson - Eclipse Electronic Systems)
> 3. Re: Qualify OPTIONS messages (Kevin P. Fleming)
> 4. Re: Qualify OPTIONS messages (Tzafrir Cohen)
> 5. Re: Qualify OPTIONS messages (Evan Borgstr?m)
> 6. Re: Qualify OPTIONS messages (Kevin P. Fleming)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 15 Aug 2006 12:15:48 -0400
> From: Evan Borgstr?m
> Subject: Re: [asterisk-dev] Qualify OPTIONS messages
> To: Asterisk Developers Mailing List
> Message-ID: <44E1F334.2090209 at ca.mci.com>
> Content-Type: text/plain; charset=UTF-8
>
>
> Sorry, I meant RFC 3261 but I'm sure you figured that out...
>
> -Evan
>
> Evan BorgstrÃ¶m wrote:
> > Actually, it is for determining if the UAC is willing to accept an
> > INVITE. RFC 3262 Section 11.2
> >
> > The response to an OPTIONS is constructed using the standard rules
> > for a SIP response as discussed in Section 8.2.6. The response code
> > chosen MUST be the same that would have been chosen had the request
> > been an INVITE. That is, a 200 (OK) would be returned if the UAS is
> > ready to accept a call, a 486 (Busy Here) would be returned if the
> > UAS is busy, etc. This allows an OPTIONS request to be used to
> > determine the basic state of a UAS, which can be an indication of
> > whether the UAS will accept an INVITE request.
> >
> > -Evan
> >
> > Joshua Colp wrote:
> >> ----- Jon SchÃ¸pzinsky wrote:
> >>> Hello
> >>>
> >>> Ive been playing around with clustering using DUNDi, and found a
> >>> problem with the way chan_sip handles the response to its qualify
> >>> OPTION messages.
> >>> If a negative response is received, such as 403, it still markes the
> >>> sip peer as being alive, which is quite a problem when using
> >>> ChanIsAvail.
> >> OPTIONS is not for determining whether the device is capable of accepting
> a call on that level, it is to determine whether the device is actually
> there and capable of receiving SIP packets. Due to the fact that it received
> a 403 back, the device is indeed there and capable of receiving/processing
> SIP packets. If we turned this into the way you want, we might even hurt
> things as depending on the SIP stack they can respond with different things.
> >>
> >>>
> >>> Med venlig hilsen
> >>>
> >> Joshua Colp
> >> Digium
> >> _______________________________________________
> >> --Bandwidth and Colocation provided by Easynews.com --
> >>
> >> asterisk-dev mailing list
> >> To UNSUBSCRIBE or update options visit:
> >> http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> > _______________________________________________
> > --Bandwidth and Colocation provided by Easynews.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> > http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 15 Aug 2006 11:24:52 -0500
> From: Tim Johnson - Eclipse Electronic Systems
>
> Subject: [asterisk-dev] Zaptel Drivers----Thanks
> To: Asterisk Developers Mailing List
> Message-ID: <44E1F554.8020004 at eclipse.sigint.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> To Keven F, Matthew F, and Steven C.
>
>
> Just want to say thanks for all the input and help. Using the
> channel(s) in clear mode was the way to go. Requires a little more
> processing to deal with the silence/idle patterns, but the data I'm now
> getting out is recognizable (after a bit reversal).
>
> Thanks again and sorry for bothering everyone.
>
> -Tim
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: tjohnson.vcf
> Type: text/x-vcard
> Size: 326 bytes
> Desc: not available
> Url :
> http://lists.digium.com/pipermail/asterisk-dev/attachments/20060815/043f182c/tjohnson-0001.vcf
>
> ------------------------------
>
> Message: 3
> Date: Tue, 15 Aug 2006 11:32:37 -0500 (CDT)
> From: "Kevin P. Fleming"
> Subject: Re: [asterisk-dev] Qualify OPTIONS messages
> To: Asterisk Developers Mailing List
> Message-ID:
> <12282528.27211155659557873.JavaMail.root at jupiler.digium.com>
> Content-Type: text/plain; charset=utf-8
>
> ----- Evan BorgstrÃ¶m wrote:
> > Actually, it is for determining if the UAC is willing to accept an
> > INVITE. RFC 3262 Section 11.2
> >
>
> That is the 'intended' use of OPTIONS, yes. However, Asterisk is using it as
> a lower-level check for connectivity and response time only.
>
> --
> Kevin P. Fleming
> Senior Software Engineer
> Digium, Inc.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 15 Aug 2006 20:00:21 +0300
> From: Tzafrir Cohen
> Subject: Re: [asterisk-dev] Qualify OPTIONS messages
> To: asterisk-dev at lists.digium.com
> Message-ID: <20060815170021.GH2731 at xorcom.com>
> Content-Type: text/plain; charset=iso-8859-1
>
> On Tue, Aug 15, 2006 at 11:32:37AM -0500, Kevin P. Fleming wrote:
> > ----- Evan Borgström wrote:
> > > Actually, it is for determining if the UAC is willing to accept an
> > > INVITE. RFC 3262 Section 11.2
> > >
> >
> > That is the 'intended' use of OPTIONS, yes. However, Asterisk is using
> > it as a lower-level check for connectivity and response time only.
> >
>
> Just a silly question: is there any way to tell from that reply (or from
> the context) that the message got to the right server? That we're not
> getting this reply from some all-denying proxy along the way?
>
> --
> Tzafrir Cohen sip:tzafrir at local.xorcom.com
> icq#16849755 iax:tzafrir at local.xorcom.com
> +972-50-7952406 jabber:tzafrir at jabber.org
> tzafrir.cohen at xorcom.com http://www.xorcom.com
>
>
> ------------------------------
>
> Message: 5
> Date: Tue, 15 Aug 2006 13:26:18 -0400
> From: Evan Borgstr?m
> Subject: Re: [asterisk-dev] Qualify OPTIONS messages
> To: Asterisk Developers Mailing List
> Message-ID: <44E203BA.3030205 at ca.mci.com>
> Content-Type: text/plain; charset=UTF-8
>
>
> True, a lot of devices use OPTIONS for pings (we do it all over the
> place), but I think Jon's point is valid. After a quick skim through of
> chan_sip.c it doesn't look like having another check of resp in
> handle_response_peerpoke for >= 400 along with != 100 that sets the peer
> state to alive but would cause ChanIsAvail to see AST_DEVICE_BUSY might
> be a handy feature (as I see a lot of people are interested in it from
> comments on voip-info.org).
>
> It doesn't look like it will break anything from my quick skim of
> chan_sip, but before I start putting together a patch I'm curious what
> are your thoughts are?
>
> -Evan
>
> Kevin P. Fleming wrote:
> > ----- Evan BorgstrÃ¶m wrote:
> >> Actually, it is for determining if the UAC is willing to accept an
> >> INVITE. RFC 3262 Section 11.2
> >>
> >
> > That is the 'intended' use of OPTIONS, yes. However, Asterisk is using it
> as a lower-level check for connectivity and response time only.
> >
>
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 15 Aug 2006 12:34:33 -0500 (CDT)
> From: "Kevin P. Fleming"
> Subject: Re: [asterisk-dev] Qualify OPTIONS messages
> To: Asterisk Developers Mailing List
> Message-ID:
> <7112321.27441155663273423.JavaMail.root at jupiler.digium.com>
> Content-Type: text/plain; charset=utf-8
>
> ----- Evan BorgstrÃ¶m wrote:
> > True, a lot of devices use OPTIONS for pings (we do it all over the
> > place), but I think Jon's point is valid. After a quick skim through
> > of
> > chan_sip.c it doesn't look like having another check of resp in
> > handle_response_peerpoke for >= 400 along with != 100 that sets the
> > peer
> > state to alive but would cause ChanIsAvail to see AST_DEVICE_BUSY
> > might
> > be a handy feature (as I see a lot of people are interested in it
> > from
> > comments on voip-info.org).
> >
>
> Seems like a reasonable thing to do, although AST_DEVICE_UNAVAILABLE might
> be better. I'm not sure how you are going to do that, though, since
> ChanIsAvail doesn't do anything different than Dial does to create a channel
> so there's no way that chan_sip can know the difference. I guess what you
> are proposing is storing a completely separate 'availability' flag for
> sip_request() to use to decide whether to make a channel available, as
> opposed to relying on the current peer_poke reachability results.
>
> --
> Kevin P. Fleming
> Senior Software Engineer
> Digium, Inc.
>
>
>
> ------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.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 25, Issue 48
> ********************************************
>
>
>  				
> ---------------------------------
>  Here's a new way to find what you're looking for - Yahoo! Answers
>  Send FREE SMS to your friend's mobile from Yahoo! Messenger Version 8. Get
> it NOW
>