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

rajesh singh prince_iter at yahoo.co.in
Thu Aug 17 02:49:34 MST 2006 

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20060817/769ffcdb/attachment.htm

More information about the asterisk-dev mailing list