<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>
<META content="MSHTML 6.00.2900.2769" name=GENERATOR></HEAD>
<BODY text=#000000 bgColor=#ffffff>
<DIV><SPAN class=542550302-24112005><FONT face=Arial color=#0000ff size=2>Are
you also implementing the "ping" keepalive as part of your
app?</FONT></SPAN></DIV>
<DIV><SPAN class=542550302-24112005><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=542550302-24112005><FONT face=Arial color=#0000ff
size=2>Mark</FONT></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT
face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Bill Michaelson
[mailto:bill@cosi.com] <BR><B>Sent:</B> Thursday, 24 November 2005 9:09
AM<BR><B>To:</B> asterisk-users@lists.digium.com<BR><B>Subject:</B>
[Asterisk-Users] Re: manager interface behavior<BR><BR></FONT></DIV>snacktime
wrote:<BR><PRE wrap=""><DIV class=moz-txt-sig>On 11/23/05, Bill Michaelson <A class=moz-txt-link-rfc2396E href="mailto:bill@cosi.com"><bill@cosi.com></A> wrote:
</DIV></PRE>
<BLOCKQUOTE type="cite"><PRE wrap=""><SPAN class=moz-txt-citetags>> </SPAN>I'm working on a manager client that I designed to hold open TCP
<SPAN class=moz-txt-citetags>> </SPAN>connection to asterisk while it is running for varoius purposes. After
<SPAN class=moz-txt-citetags>> </SPAN>being puzzled by unexpected behavior, I realized that the server closes
<SPAN class=moz-txt-citetags>> </SPAN>the connection after it completes an "originate" action - or at least it
<SPAN class=moz-txt-citetags>> </SPAN>does in the case of my test transactions.
<SPAN class=moz-txt-citetags>></SPAN>
<SPAN class=moz-txt-citetags>> </SPAN>I solicit opinions: is this a feature or a bug?
</PRE></BLOCKQUOTE><PRE wrap=""><!---->
I've never seen that behavior and I've written several clients for the
manager api. I guess it's possible that a particular combination of
variables in the request could trigger an error that makes asterisk do
that. I would try issuing the same originate by telneting in
manually and see what happens. That way you can positively rule out
your client being the one that's disconnecting.
</PRE>to which I reply:<BR><BR>That's the first thing I did, and it confirmed
the behavior (see below). To be precise, the disconnect occurs after the
Newchannel report. So I infer that you think it is inappropriate.
I've recoded the client so that it immediately reconnects. Anybody
actually tried this? I can imagine that the developer might have assumed
that such a request would likely come from a transient client, and that it
would be helpful to terminate the connection. But if so, I don't think
it's the right decision. Maybe it's just an oversight. Any other
opinions? I'm too lazy to read the server side
code.<BR><BR><TT>bill@phex:~> telnet hack.cosi.com 5038<BR>Trying
192.168.10.26...<BR>Connected to hack.cosi.com.<BR>Escape character is
'^]'.<BR>Asterisk Call Manager/1.0<BR>action: login<BR>username:
bill<BR>secret: dontell<BR><BR>Response: Success<BR>Message: Authentication
accepted<BR><BR>action: originate<BR>callerid: 0000000000<BR>context:
default<BR>priority: 1<BR>exten: 212<BR>channel: Local/762<BR><BR>Response:
Success<BR>Message: Originate successfully queued<BR><BR>Event:
Newchannel<BR>Privilege: call,all<BR>Channel:
Local/762@default-b315,2<BR>State: Ring<BR>CallerID:
<unknown><BR>CallerIDName: <unknown><BR>Uniqueid:
1132773921.72<BR><BR>Connection closed by foreign host.<BR>bill@phex:~>
</TT><BR></BLOCKQUOTE></BODY></HTML>