date:20040625

Re: [Asterisk-Dev] Advanced ADSI scripts

2004-06-25 Thread alex

Actually, I don't see anything in there that asterisk compiler won't 
support...Maybe I'm missing something?

-alex

> You are going to need to add support for more of the
> full version 2 adsi spec to the asterisk parser/compiler
> 
> For example this is for the Altigen system with AAstra 390
> you can see from this what a small subset of the adsi spec
> the  asterisk parse/compiler supports

> 
> 
> ;
> ;  Output Settings
> ;
> CPEType=NORTEL390
> OutputFormat=ALTIGEN
> 
> Volume=50
> Margin=400
> CASTone=120
> CPEAck=Yes
> Disconnect=Yes
> Expanded=Yes
> 
> ;
> ;  Line Definitions
> ;
> DefineLine Line01=Normal,Center,WrapOFF,
> DefineLine Line02=Normal,Center,WrapOFF,AltiTouch Plus
> DefineLine Line03=Normal,Center,WrapOFF,
> DefineLine Line04=Normal,Center,WrapOFF,
> DefineLine Line05=Normal,Center,WrapOFF,V 2.3.2.11.28
> DefineLine Line06=Normal,Center,WrapOFF,Powered by
> DefineLine Line07=Normal,Center,WrapOFF,STL Software
> DefineLine Line08=Normal,Center,WrapOFF,www.sayson.com
> DefineLine Line09=Normal,Center,WrapOFF,
> DefineLine Line10=Normal,Center,WrapOFF,
> DefineLine Line11=Normal,Center,WrapOFF,
> DefineLine Line12=Normal,Center,WrapOFF,
> DefineLine Line13=Normal,Center,WrapOFF,(2 of 2)
> DefineLine Line14=Normal,Left,WrapOFF,Inbound Call:
> DefineLine Line15=Normal,Left,WrapOFF,Connected to:
> DefineLine Line16=Normal,Left,WrapON,Call Waiting...
> DefineLine Line17=Normal,Left,WrapON,$Call1s$Call1p
> DefineLine Line18=Normal,Center,WrapOFF,Enter 2 Digit Park #
> DefineLine Line19=Normal,Center,WrapOFF,Enter Extension
> DefineLine Line20=Normal,Center,WrapOFF,and press DONE
> DefineLine Line21=Normal,Center,WrapON,Ringing & ParkedCall Pickup
> DefineLine Line22=Normal,Center,WrapON,Extension ManagementOptions
> DefineLine Line23=Normal,Center,WrapON,More Extension MgmntOptions
> DefineLine Line24=Normal,Center,WrapOFF,Call Forwarding
> DefineLine Line25=Normal,Center,WrapOFF,Change Greeting
> DefineLine Line26=Normal,Center,WrapOFF,Station Login
> DefineLine Line27=Normal,Center,WrapOFF,Station Logout
> DefineLine Line28=Normal,Center,WrapOFF,Extension Status
> DefineLine Line29=Normal,Center,WrapOFF,Voicemail
> DefineLine Line30=Normal,Center,WrapOFF,Workgroup Options
> DefineLine Line31=Normal,Center,WrapOFF,WorkGroup Login
> DefineLine Line32=Normal,Center,WrapOFF,WorkGroup Logout
> DefineLine Line33=Normal,Center,WrapOFF,Workgroup Ready
> DefineLine Line34=Normal,Center,WrapOFF,WorkGroup Wait
> DefineLine Line35=Normal,Center,WrapOFF,Speed Dial
> DefineLine Line36=Normal,Center,WrapOFF,Dial Options
> DefineLine Line37=Normal,Center,WrapOFF,Dial by Name
> DefineLine Line38=Normal,Center,WrapOFF,Last Number Dialed
> DefineLine Line39=Normal,Center,WrapOFF,Dial Last Caller
> DefineLine Line40=Normal,Center,WrapOFF,Page through Trunk
> DefineLine Line41=Normal,Center,WrapOFF,Page over Audio
> DefineLine Line42=Normal,Center,WrapOFF,Hands Free Options
> DefineLine Line43=Normal,Center,WrapOFF,Intercom Mode
> DefineLine Line44=Normal,Center,WrapOFF,Dialtone Mode
> DefineLine Line45=Normal,Center,WrapON,Enter NumberOr Choose an Option
> DefineLine Line46=Normal,Center,WrapOFF,Enter Extension #
> DefineLine Line47=Normal,Center,WrapON,Enter 2 DigitAutoattendant
> Number
> DefineLine Line48=Normal,Center,WrapOFF,AutoAttendant Number
> DefineLine Line49=Normal,Center,WrapOFF,In Conference
> DefineLine Line50=Normal,Center,WrapOFF,Manual Operation
> DefineLine Line51=Normal,Left,WrapOFF,  Please Wait ...
> DefineLine Line52=Normal,Center,WrapOFF,Demo
> DefineLine Line53=Normal,Left,WrapOFF,Paging Options
> DefineLine Line54=Normal,Center,WrapOFF,Park Call
> DefineLine Line55=Normal,Center,WrapOFF,Park and Page
> DefineLine Line56=Normal,Center,WrapOFF,Password Menu
> DefineLine Line57=Normal,Center,WrapON,Enter Number andpress Conf.In
> DefineLine Line58=Normal,Center,WrapOFF,Enter Passcode
> DefineLine Line59=Normal,Left,WrapOFF,Intercom Call:
> DefineLine Line60=Normal,Center,WrapOFF,Directory Services
> DefineLine Line61=Normal,Center,WrapON,Call is on HoldDo not hang up
> DefineLine Line62=Normal,Center,WrapOFF,Use Back to Retrieve
> 
> ;
> ;  SoftKeys
> ;
> 
> ;
> ;   Answer
> ;
> SoftKey=SK_01
>Label=Answer
>SetHookState OffHook
> EndSoftKey
> 
> 
> ;
> ;   Flash
> ;
> SoftKey=SK_02
>Label=Flash
>LongLabel=Flash/Tsfr/Conf
>SetState 3
>ClearDisplay
>SetDisplay NULL,0,0
>SetDisplay Line50,2,3
>SetHookState Link
>SetSoftKey 0SK_02,Normal,SK_03,Normal,
> EndSoftKey
> 
> 
> ;

Re: [Asterisk-Dev] Stable branch usable? Development branch better?

2004-06-25 Thread Brian

Paul Mahler wrote:
Is the stable branch usable? Is there ever going to be a 1.0 release?
 
Should I be using the "stable" branch or the development branch? The 
development branch seems to have more fixes than the stable branch. It 
looks like fixes going into the release branch aren't going into the 
stable branch.
 
TKS
 
Paul
 
*
Paul Mahler*
[EMAIL PROTECTED]  	

*
Signate, LLC*
665 Third Street
Suite 100
San Francisco, CA
 94107-1901
 Asterisk Services and Training
 

 

 

 
From what I've heard at this point cvs-HEAD is more "stable" then the 
1.0-stable branch
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Advanced ADSI scripts

2004-06-25 Thread TC

You are going to need to add support for more of the
full version 2 adsi spec to the asterisk parser/compiler

For example this is for the Altigen system with AAstra 390
you can see from this what a small subset of the adsi spec
the  asterisk parse/compiler supports


;
;  Output Settings
;
CPEType=NORTEL390
OutputFormat=ALTIGEN

Volume=50
Margin=400
CASTone=120
CPEAck=Yes
Disconnect=Yes
Expanded=Yes

;
;  Line Definitions
;
DefineLine Line01=Normal,Center,WrapOFF,
DefineLine Line02=Normal,Center,WrapOFF,AltiTouch Plus
DefineLine Line03=Normal,Center,WrapOFF,
DefineLine Line04=Normal,Center,WrapOFF,
DefineLine Line05=Normal,Center,WrapOFF,V 2.3.2.11.28
DefineLine Line06=Normal,Center,WrapOFF,Powered by
DefineLine Line07=Normal,Center,WrapOFF,STL Software
DefineLine Line08=Normal,Center,WrapOFF,www.sayson.com
DefineLine Line09=Normal,Center,WrapOFF,
DefineLine Line10=Normal,Center,WrapOFF,
DefineLine Line11=Normal,Center,WrapOFF,
DefineLine Line12=Normal,Center,WrapOFF,
DefineLine Line13=Normal,Center,WrapOFF,(2 of 2)
DefineLine Line14=Normal,Left,WrapOFF,Inbound Call:
DefineLine Line15=Normal,Left,WrapOFF,Connected to:
DefineLine Line16=Normal,Left,WrapON,Call Waiting...
DefineLine Line17=Normal,Left,WrapON,$Call1s$Call1p
DefineLine Line18=Normal,Center,WrapOFF,Enter 2 Digit Park #
DefineLine Line19=Normal,Center,WrapOFF,Enter Extension
DefineLine Line20=Normal,Center,WrapOFF,and press DONE
DefineLine Line21=Normal,Center,WrapON,Ringing & ParkedCall Pickup
DefineLine Line22=Normal,Center,WrapON,Extension ManagementOptions
DefineLine Line23=Normal,Center,WrapON,More Extension MgmntOptions
DefineLine Line24=Normal,Center,WrapOFF,Call Forwarding
DefineLine Line25=Normal,Center,WrapOFF,Change Greeting
DefineLine Line26=Normal,Center,WrapOFF,Station Login
DefineLine Line27=Normal,Center,WrapOFF,Station Logout
DefineLine Line28=Normal,Center,WrapOFF,Extension Status
DefineLine Line29=Normal,Center,WrapOFF,Voicemail
DefineLine Line30=Normal,Center,WrapOFF,Workgroup Options
DefineLine Line31=Normal,Center,WrapOFF,WorkGroup Login
DefineLine Line32=Normal,Center,WrapOFF,WorkGroup Logout
DefineLine Line33=Normal,Center,WrapOFF,Workgroup Ready
DefineLine Line34=Normal,Center,WrapOFF,WorkGroup Wait
DefineLine Line35=Normal,Center,WrapOFF,Speed Dial
DefineLine Line36=Normal,Center,WrapOFF,Dial Options
DefineLine Line37=Normal,Center,WrapOFF,Dial by Name
DefineLine Line38=Normal,Center,WrapOFF,Last Number Dialed
DefineLine Line39=Normal,Center,WrapOFF,Dial Last Caller
DefineLine Line40=Normal,Center,WrapOFF,Page through Trunk
DefineLine Line41=Normal,Center,WrapOFF,Page over Audio
DefineLine Line42=Normal,Center,WrapOFF,Hands Free Options
DefineLine Line43=Normal,Center,WrapOFF,Intercom Mode
DefineLine Line44=Normal,Center,WrapOFF,Dialtone Mode
DefineLine Line45=Normal,Center,WrapON,Enter NumberOr Choose an Option
DefineLine Line46=Normal,Center,WrapOFF,Enter Extension #
DefineLine Line47=Normal,Center,WrapON,Enter 2 DigitAutoattendant
Number
DefineLine Line48=Normal,Center,WrapOFF,AutoAttendant Number
DefineLine Line49=Normal,Center,WrapOFF,In Conference
DefineLine Line50=Normal,Center,WrapOFF,Manual Operation
DefineLine Line51=Normal,Left,WrapOFF,  Please Wait ...
DefineLine Line52=Normal,Center,WrapOFF,Demo
DefineLine Line53=Normal,Left,WrapOFF,Paging Options
DefineLine Line54=Normal,Center,WrapOFF,Park Call
DefineLine Line55=Normal,Center,WrapOFF,Park and Page
DefineLine Line56=Normal,Center,WrapOFF,Password Menu
DefineLine Line57=Normal,Center,WrapON,Enter Number andpress Conf.In
DefineLine Line58=Normal,Center,WrapOFF,Enter Passcode
DefineLine Line59=Normal,Left,WrapOFF,Intercom Call:
DefineLine Line60=Normal,Center,WrapOFF,Directory Services
DefineLine Line61=Normal,Center,WrapON,Call is on HoldDo not hang up
DefineLine Line62=Normal,Center,WrapOFF,Use Back to Retrieve

;
;  SoftKeys
;

;
;   Answer
;
SoftKey=SK_01
   Label=Answer
   SetHookState OffHook
EndSoftKey


;
;   Flash
;
SoftKey=SK_02
   Label=Flash
   LongLabel=Flash/Tsfr/Conf
   SetState 3
   ClearDisplay
   SetDisplay NULL,0,0
   SetDisplay Line50,2,3
   SetHookState Link
   SetSoftKey 0SK_02,Normal,SK_03,Normal,
EndSoftKey


;
;   Hangup
;
SoftKey=SK_03
   Label=Hangup
   SetState 1
   SetHookState OnHook
   Delay 25
   JumpTo #00
   SetEvent 1
EndSoftKey


;
;   OK
;   Button 4 - Corp Branding verification OK button
;
SoftKey=SK_04
   Label=

Re: [Asterisk-Dev] rfc3581 - implemented correctly in * ?

2004-06-25 Thread Ryan Courtnage

I finished testing this, and the results are in 

I hacked chan_sip to build the Via header field in this order:

Via: SIP/2.0/UDP 192.168.1.102:5060;rport;branch=z9hG4bK509ab7ad

... makes no difference for the UIP200 phones.  

So, it's probably a bug in the phone firmware.  I've emailed Uniden to verify, 
and will follow up with them via phone on Monday.

Ryan

I normally don't backwards top-post, but since I was replying to myself, I got 
a bit confused - Hey, it's Friday :D

On Friday 25 June 2004 16:29, John Todd wrote:
> You've also got your bottom-posting order in the wrong order.  :-)
>
> As far as I know, things that are separated by ";" characters can be
> moved around each other; ordering should not be important.  I can't
> find the RFC that says this, so I'm possibly wrong with this.
>
> I will say that every example I can find has "rport" right after the
> IP address (as in your example #6 below.)  I don't know if Asterisk
> supports the "rport=" options, either.
>
> Let us know of the results of your experiment.  If the Uniden works
> after you move things around, I think a ticket should be opened (by
> you, since you'll have the empirical data) to suggest a change to
> Asterisk so that it sends the "expected" ordering (even though it
> perhaps shouldn't matter.)
>
> JT
>
> At 1:50 PM -0600 on 6/25/04, Ryan Courtnage wrote:
> >Hmmm, I think * may have the syntax wrong:
> >
> >from http://www.ietf.org/rfc/rfc3581.txt :
> >
> >snip
> >5.  Syntax
> >
> >The syntax for the "rport" parameter is:
> >
> >response-port = "rport" [EQUAL 1*DIGIT]
> >
> >This extends the existing definition of the Via header field
> >parameters, so that its BNF now looks like:
> >
> >via-params=  via-ttl / via-maddr
> > / via-received / via-branch
> > / response-port / via-extension
> >
> >6.  Example
> >
> >A client sends an INVITE to a proxy server which looks like, in part:
> >
> >INVITE sip:[EMAIL PROTECTED] SIP/2.0
> >Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
> >snip
> >
> >
> >* is sending as:
> >
> >Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK4b9f493c;rport
> >
> >ie: rport is in the wrong spot.  Don't know this makes a difference.
> >
> >I'll try hacking chan_sip.c myself to see if the order of the parameters
> >matter.
> >
> >Ryan
> >
> >On Friday 25 June 2004 12:44, Ryan Courtnage wrote:
> >>  Hi,
> >>
> >>  Bug #1862 implemented RFC3581.
> >>
> >>  I'm no expert, but it appears that this change appends ";rport" to the
> >> end of the VIA header field on INVITEs sent to SIP phones:
> >>
> >>  Message Header
> >>  Via: SIP/2.0/UDP
> >> 192.168.1.102:5060;branch=z9hG4bK4b9f493c;rport
> >>
> >>  Problem is, this breaks dialing to Uniden UIP200 phones (they don't
> >> reply back when the Via header has ";rport" on the end).
> >>
> >>  So, do I need to put pressure on Uniden to fix this, or has RFC2581
> >> been implemented in * incorrectly ?
> >>
> >>  Thanks for any help on this - I'm currently stuck using * builds
> >> previous to Bug #1862.
> >>
> >>  Ryan
> >>
> >>  PS: I'm usind nat=no ... if that matters.
> >>
> >>  --
> >>  ..
> >>  Ryan Courtnage
> >>  Coalescent Systems Inc
> >>  403.244.8089
> >>  www.voxbox.ca
> >>  ___
> >>  Asterisk-Dev mailing list
> >>  [EMAIL PROTECTED]
> >>  http://lists.digium.com/mailman/listinfo/asterisk-dev
> >>  To UNSUBSCRIBE or update options visit:
> >> http://lists.digium.com/mailman/listinfo/asterisk-dev
> >
> >___
> >Asterisk-Dev mailing list
> >[EMAIL PROTECTED]
> >http://lists.digium.com/mailman/listinfo/asterisk-dev
> >To UNSUBSCRIBE or update options visit:
> >http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> ___
> Asterisk-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
..
Ryan Courtnage
Coalescent Systems Inc
403.244.8089
www.voxbox.ca
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] rfc3581 - implemented correctly in * ?

2004-06-25 Thread John Todd

You've also got your bottom-posting order in the wrong order.  :-)
As far as I know, things that are separated by ";" characters can be 
moved around each other; ordering should not be important.  I can't 
find the RFC that says this, so I'm possibly wrong with this.

I will say that every example I can find has "rport" right after the 
IP address (as in your example #6 below.)  I don't know if Asterisk 
supports the "rport=" options, either.

Let us know of the results of your experiment.  If the Uniden works 
after you move things around, I think a ticket should be opened (by 
you, since you'll have the empirical data) to suggest a change to 
Asterisk so that it sends the "expected" ordering (even though it 
perhaps shouldn't matter.)

JT
At 1:50 PM -0600 on 6/25/04, Ryan Courtnage wrote:
Hmmm, I think * may have the syntax wrong:
from http://www.ietf.org/rfc/rfc3581.txt :
snip
5.  Syntax
   The syntax for the "rport" parameter is:
   response-port = "rport" [EQUAL 1*DIGIT]
   This extends the existing definition of the Via header field
   parameters, so that its BNF now looks like:
   via-params=  via-ttl / via-maddr
/ via-received / via-branch
/ response-port / via-extension
6.  Example
   A client sends an INVITE to a proxy server which looks like, in part:
   INVITE sip:[EMAIL PROTECTED] SIP/2.0
   Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
snip
* is sending as:
Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK4b9f493c;rport
ie: rport is in the wrong spot.  Don't know this makes a difference. 

I'll try hacking chan_sip.c myself to see if the order of the parameters
matter.
Ryan
On Friday 25 June 2004 12:44, Ryan Courtnage wrote:
 Hi,
 Bug #1862 implemented RFC3581.
 I'm no expert, but it appears that this change appends ";rport" to the end
 of the VIA header field on INVITEs sent to SIP phones:
 Message Header
 Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK4b9f493c;rport
 Problem is, this breaks dialing to Uniden UIP200 phones (they don't reply
  back when the Via header has ";rport" on the end).
 So, do I need to put pressure on Uniden to fix this, or has RFC2581 been
 implemented in * incorrectly ?
 Thanks for any help on this - I'm currently stuck using * builds previous
 to Bug #1862.
 Ryan
 PS: I'm usind nat=no ... if that matters.
 --
 ..
 Ryan Courtnage
 Coalescent Systems Inc
 403.244.8089
 www.voxbox.ca
 ___
 Asterisk-Dev mailing list
 [EMAIL PROTECTED]
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Getting URL to IAX Client Agent

2004-06-25 Thread Jean-Denis Girard

Steve Kann wrote:
Jean-Denis:  are you building your client based on iaxclient?  If not, 
why not?

Yes, my client is built on libiaxclient, and mozilla's framework (XUL + 
 JS code) so adding a browser is easy...

--
Jean-Denis Girard

Essential Software - Ingénierie Informatique
Solutions Linux & Open Source en Polynésie française

http://www.esoft.pf/
Tél: (689) 54 12 95

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Getting URL to IAX Client Agent

2004-06-25 Thread Tilghman Lesher

On Friday 25 June 2004 13:50, Steven Sokol wrote:
> > Navnit Chachan wrote:
> > > I am using IAX Phone from skol associates
>
> I'm working on adding URL support to IAX Phone.  It will simply pop the
> default browser with the URL.  The bigger question is: how do you want to
> go about _sending_ the URLs?  Copy/paste/send?
>
> Click a button that pops up a dialog asking you to enter the URL?
> The dialog box could contain a set of "Speed Dial URLs" for commonly
> transmitted info.  It could also contain a drop-down list for recently sent
> URLs.  Would that work?

You might want to check to see how the application SendURL transmits the
URL and do something compatible.

-- 
Tilghman
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] Getting URL to IAX Client Agent

2004-06-25 Thread Jean-Denis Girard

Steven Sokol wrote:
I'm working on adding URL support to IAX Phone.  It will simply pop the
default browser with the URL.  The bigger question is: how do you want to go
about _sending_ the URLs?  Copy/paste/send?
Click a button that pops up a dialog asking you to enter the URL?
The dialog box could contain a set of "Speed Dial URLs" for commonly
transmitted info.  It could also contain a drop-down list for recently sent
URLs.  Would that work?
Thanks,
Steve

Well, here is my current patch to libiaxclient. As you will see, it does 
not support sending an URL from the client, just receiving URL which may 
be sent by * via Dial+URL (or Queue+URL), usefull in call center 
environment.
I don't really know how to best handle sending an URL from the client, 
but copy/paste/send seems ok to me.

Thanks,
--
Jean-Denis Girard

Essential Software - Ingénierie Informatique
Solutions Linux & Open Source en Polynésie française

http://www.esoft.pf/
Tél: (689) 54 12 95

diff -Naur iaxclient-20040617/lib/iaxclient.h iaxclient-20040617-JDG/lib/iaxclient.h
--- iaxclient-20040617/lib/iaxclient.h  2004-06-10 14:01:23.0 -1000
+++ iaxclient-20040617-JDG/lib/iaxclient.h  2004-06-17 14:40:30.135164832 -1000
@@ -47,6 +47,7 @@
 #define IAXC_EVENT_TEXT1
 #define IAXC_EVENT_LEVELS  2
 #define IAXC_EVENT_STATE   3
+#define IAXC_EVENT_URL 4   /* URL push via IAX(2) */
 
 #define IAXC_CALL_STATE_FREE   0
 #define IAXC_CALL_STATE_ACTIVE (1<<1)
@@ -62,7 +63,11 @@
 #define IAXC_TEXT_TYPE_FATALERROR  4
 #define IAXC_TEXT_TYPE_IAX 5
 
-
+#define IAXC_URL_URL   1   /* URL received */
+#define IAXC_URL_LDCOMPLETE2   /* URL loading complete */
+#define IAXC_URL_LINKURL   3   /* URL link request */
+#define IAXC_URL_LINKREJECT4   /* URL link reject */
+#define IAXC_URL_UNLINK5   /* URL unlink */
 
 #define IAXC_EVENT_BUFSIZ  256
 struct iaxc_ev_levels {
@@ -85,12 +90,19 @@
char local_context[IAXC_EVENT_BUFSIZ];
 };
 
+struct iaxc_ev_url {
+   int callNo;
+   int type;
+   char url[IAXC_EVENT_BUFSIZ];
+};
+
 typedef struct iaxc_event_struct {
int type;
union {
struct iaxc_ev_levels   levels;
struct iaxc_ev_text text;
struct iaxc_ev_call_state   call;
+   struct iaxc_ev_url  url;
} ev;
 } iaxc_event;
 
diff -Naur iaxclient-20040617/lib/iaxclient_lib.c 
iaxclient-20040617-JDG/lib/iaxclient_lib.c
--- iaxclient-20040617/lib/iaxclient_lib.c  2004-06-10 14:01:23.0 -1000
+++ iaxclient-20040617-JDG/lib/iaxclient_lib.c  2004-06-17 14:40:30.136164680 -1000
@@ -509,6 +509,52 @@
 iaxc_post_event(ev);
 }
 
+/* handle IAX URL events */
+void handle_url_event( struct iax_event *e, int callNo ) {
+   iaxc_event ev;
+
+   if(callNo < 0) return;
+
+   ev.ev.url.callNo = callNo;
+   ev.type = IAXC_EVENT_URL;
+   strcpy( ev.ev.url.url, "" );
+
+   switch( e->subclass ) {
+   case AST_HTML_URL:
+   ev.ev.url.type = IAXC_URL_URL;
+   if( e->datalen ) {
+   if( e->datalen > IAXC_EVENT_BUFSIZ ) {
+   fprintf( stderr, "ERROR: URL too long %d > 
%d\n", 
+   e->datalen, IAXC_EVENT_BUFSIZ 
);
+   } else {
+   strncpy( ev.ev.url.url, e->data, e->datalen );
+   }
+   }
+   fprintf( stderr, "URL:%s\n", ev.ev.url.url );
+   break;
+   case AST_HTML_LINKURL:
+   ev.ev.url.type = IAXC_URL_LINKURL;
+   fprintf( stderr, "LINKURL event\n" );
+   break;
+   case AST_HTML_LDCOMPLETE:
+   ev.ev.url.type = IAXC_URL_LDCOMPLETE;
+   fprintf( stderr, "LDCOMPLETE event\n" );
+   break;
+   case AST_HTML_UNLINK:
+   ev.ev.url.type = IAXC_URL_UNLINK;
+   fprintf( stderr, "UNLINK event\n" );
+   break;
+   case AST_HTML_LINKREJECT:
+   ev.ev.url.type = IAXC_URL_LINKREJECT;
+   fprintf( stderr, "LINKREJECT event\n" );
+   break;
+   default:
+   fprintf( stderr, "Unknown URL event %d\n", e->subclass );
+   break;
+   }
+iaxc_post_event( ev );
+}
+
 void handle_audio_event(struct iax_event *e, int callN

Re: [Asterisk-Dev] Getting URL to IAX Client Agent

2004-06-25 Thread Steve Kann

It should be pretty easy to add URL support to libiaxclient; It only 
took me about 20 minutes to add support for TEXT frames.

Jean-Denis:  are you building your client based on iaxclient?  If not, 
why not?

-SteveK
On Jun 25, 2004, at 1:56 PM, Jean-Denis Girard wrote:
Navnit Chachan wrote:
I am using IAX Phone from skol associates
I may be wrong, but as far as I know:
The only IAX client that supports URL is gnophone, which is basically 
dead since it's only IAX1... There is no support for URL in the 
libiaxclient on which IAXPhone is based.

I'm currently working on yet another iax2 client with support for URL, 
but it's too early in the development to show anything.

--
Jean-Denis Girard

Essential Software - Ingénierie Informatique
Solutions Linux & Open Source en Polynésie française

http://www.esoft.pf/
Tél: (689) 54 12 95

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

RE: [Asterisk-Dev] Getting URL to IAX Client Agent

2004-06-25 Thread Steven Sokol

> Navnit Chachan wrote:
> > I am using IAX Phone from skol associates

I'm working on adding URL support to IAX Phone.  It will simply pop the
default browser with the URL.  The bigger question is: how do you want to go
about _sending_ the URLs?  Copy/paste/send?

Click a button that pops up a dialog asking you to enter the URL?
The dialog box could contain a set of "Speed Dial URLs" for commonly
transmitted info.  It could also contain a drop-down list for recently sent
URLs.  Would that work?

Thanks,

Steve

> 
> I may be wrong, but as far as I know:
> 
> The only IAX client that supports URL is gnophone, which is basically
> dead since it's only IAX1... There is no support for URL in the
> libiaxclient on which IAXPhone is based.
> 
> I'm currently working on yet another iax2 client with support for URL,
> but it's too early in the development to show anything.
> 
> --
> Jean-Denis Girard
> 
> 
> Essential Software - Ingénierie Informatique
> Solutions Linux & Open Source en Polynésie française
> 
> http://www.esoft.pf/
> Tél: (689) 54 12 95
> 
> 
> ___
> Asterisk-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev


___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [Asterisk-Dev] rfc3581 - implemented correctly in * ?

2004-06-25 Thread Ryan Courtnage

Hmmm, I think * may have the syntax wrong:

from http://www.ietf.org/rfc/rfc3581.txt :

snip
5.  Syntax

   The syntax for the "rport" parameter is:

   response-port = "rport" [EQUAL 1*DIGIT]

   This extends the existing definition of the Via header field
   parameters, so that its BNF now looks like:

   via-params=  via-ttl / via-maddr
/ via-received / via-branch
/ response-port / via-extension

6.  Example

   A client sends an INVITE to a proxy server which looks like, in part:

   INVITE sip:[EMAIL PROTECTED] SIP/2.0
   Via: SIP/2.0/UDP 10.1.1.1:4540;rport;branch=z9hG4bKkjshdyff
snip


* is sending as:

Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK4b9f493c;rport

ie: rport is in the wrong spot.  Don't know this makes a difference.  

I'll try hacking chan_sip.c myself to see if the order of the parameters 
matter.

Ryan


On Friday 25 June 2004 12:44, Ryan Courtnage wrote:
> Hi,
>
> Bug #1862 implemented RFC3581.
>
> I'm no expert, but it appears that this change appends ";rport" to the end
> of the VIA header field on INVITEs sent to SIP phones:
>
> Message Header
> Via: SIP/2.0/UDP 192.168.1.102:5060;branch=z9hG4bK4b9f493c;rport
>
> Problem is, this breaks dialing to Uniden UIP200 phones (they don't reply
>  back when the Via header has ";rport" on the end).
>
> So, do I need to put pressure on Uniden to fix this, or has RFC2581 been
> implemented in * incorrectly ?
>
> Thanks for any help on this - I'm currently stuck using * builds previous
> to Bug #1862.
>
> Ryan
>
> PS: I'm usind nat=no ... if that matters.
>
> --
> ..
> Ryan Courtnage
> Coalescent Systems Inc
> 403.244.8089
> www.voxbox.ca
> ___
> Asterisk-Dev mailing list
> [EMAIL PROTECTED]
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[Asterisk-Dev] Stable branch usable? Development branch better?

2004-06-25 Thread Paul Mahler




Is the stable branch 
usable? Is there ever going to be a 1.0 release? 
 
Should I be using 
the "stable" branch or the development branch? The development branch seems to 
have more fixes than the stable branch. It looks like fixes going into the 
release branch aren't going into the stable branch.
 
TKS
 
Paul
 





  
  
Paul 
  Mahler [EMAIL PROTECTED] 
  

  Signate, LLC665 Third 
  StreetSuite 100San Francisco, 
  CA 94107-1901 Asterisk Services and 
  Training
 
 
 
 
<>

Re: [Asterisk-Dev] Advanced ADSI scripts

Re: [Asterisk-Dev] Stable branch usable? Development branch better?

Re: [Asterisk-Dev] Advanced ADSI scripts

Re: [Asterisk-Dev] rfc3581 - implemented correctly in * ?

Re: [Asterisk-Dev] rfc3581 - implemented correctly in * ?

Re: [Asterisk-Dev] Getting URL to IAX Client Agent

Re: [Asterisk-Dev] Getting URL to IAX Client Agent

Re: [Asterisk-Dev] Getting URL to IAX Client Agent

Re: [Asterisk-Dev] Getting URL to IAX Client Agent

RE: [Asterisk-Dev] Getting URL to IAX Client Agent

Re: [Asterisk-Dev] rfc3581 - implemented correctly in * ?

[Asterisk-Dev] Stable branch usable? Development branch better?

12 matches

Site Navigation

Mail list logo

Footer information