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