previking-devel — discussion of previking development

[PreViking-devel] previous message and open source cell phone system

[Abul K. <abu...@ya...>]

Hi all,

Please ignore my previous message about Linejack POTS application.

I found out that GSM 900 cellular phone is the cheapest phone system to
deploy compared to any Computer telephony based system.

Previking with Linejack or NMS cards are still good for calling card
gateways for International long distance. I am interested in this
application. Could anyone tell me if there are many previking based
systems deployed worldwide for call terminations - so that if I wanted to
use a previking based gateway, I could have transactions with these
termination gateway owners. Is that how Telesave works, or are you guys
using other carriers to terminate your calls? For telesave guys, I have
access to a very good termination location for a large number of East
Londoners from Bangladesh who mostly call a place there called Sylhet. I
would like to put a previking based termination gateway there starting
from a single T1 to multiple T1's, if you guys have a need for it.

It seems to me while everyone is busy writing open source codes for
gateways (Previking), IVR's (Bayonne) and softswitches (Vovida's VOCAL)
the Telecom world has already created a new business model based on Cell
Phones. Today there are close to 800 million cell phones world-wide and
they are increasing everyday specially in emerging and developing
countries where there are no extensive copper last mile network deployed.
The projection is that by 2006 there will be close to 2 billion cell phone
users.

The reason I bring this up is that all the open source codes written so
far can be used in this new cell phone world as well. There are two
competing standards in mobile telephony. The Qualcomm based CDMA (CDMA2000
for 3G) and GSM (W-CDMA for 3G). Although CDMA seems to be a better
technology (since GSM also will adopt this in the future), GSM for now is
the winner and will remain so for voice services. People predict that most
of the mobile internet users will prefer the CDMA2000 technology. The
reason for 70% market-share of GSM (compared to 13% for CDMA) is that it
seems to be a more open standard than the partly proprietary CDMA, and due
to that there are more vendors offering cheaper equipments.

Because of economies of scale (600 million) the GSM 900/1800 handset will
be the cheapest most powerful telephony and radio device ever built. To
leverage this device as well the GSM radio interfaces, the only code base
we need is a combination of softswitch for MSC and some other parts like
HLR, VLR, Vocoders, BSC & BTS software etc. VLR and HLR are basically high
speed real time databases.

I know that resources are limited for the open source teams in terms of
coders but I just wanted to find out if anyone has similar thoughts and if
there could be a future initiative for an open source cellular phone
system based on the GSM/GPRS/EDGE/W-CDMA technology which is currently the
winning camp.

Hopefully this was not a total waste of time for list users.

Abul Kalam

__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

[PreViking-devel] Quicknet Phonejack POTS application

[Abul K. <abu...@ya...>]

Hopefully you guys have received the Quicknet Linejack ISA card. Any
progress on Previking working with Linejack.

I am ready to start a trial with Quicknet phonejacks working with
Previking and I Have several questions.

- Does Previking support multiple ISA phonejacks in a Linux box and if
yes, what is max. limit if I use a ISA passive backplane.

- The same question for PCI phonejacks.

- If the above is not supported now, how difficult will it be to modify
Previking to include the above support.

- I am thinking about a project where Previking linux boxes will be
deployed in a corporate intranet or even give it to ITSP subscribers using
POTS port only - for a setup like this where I may have a large number of
linux boxes running Previking on them, is there a theoretical limit to how
many boxes we can run in a network, or is it unlimited.

- Are you currently running Previking at your different terminating points
for Telesave or are you interfacing with other termination gateways using
H.323/MGCP or SIP - which raises the other question, is H.323 the only
protocol supported now?

- On a network running a number of linux boxes, can we centralize billing,
gate-keeping, pre-paid service etc.

As far as I understand it, the hardware options for Previking are NMS AG &
CG cards and Quicknet Phonejack & Linejack (I am not sure of the Phonejack
PCI). Are there any other cheap hardware like any linux compatible modems
that will have acceptable sound quality?

I am trying to find the cheapest and most scalable solution based on the
previking linux box. For most motherboards, there is only 4-5 PCI slots
available - that is why I want to use PCI cards and possibly cards that
are cheaper than the $160 Quicknet phonejack PCI. Please make some
suggestions on that.

The AG and CG cards are expensive and are much bigger than my needs for
distributed functions. But a PICA 4 port PCI or ISA is also a good
alternative. Do you think this is an option?

Also I would like to personally discuss this with Zaheer or Abdul Wahid.
Please let me know what are good hours to catch you at your office.

Thanks,

Abul Kalam
Los Angeles
213-897-1838


__________________________________________________
Do You Yahoo!?
Send FREE Valentine eCards with Yahoo! Greetings!
http://greetings.yahoo.com

Re: [PreViking-devel] Alive?

[Zaheer M. <za...@gr...>]

Yes we are.

PreViking 0.5.0 is imminent, as well as the helper server infotel 0.1.0.

Regards

Zaheer
On Mon, 2002-01-07 at 16:11, Jeremy McNamara wrote:
> I haven't heard anything from this list latetly... Are you guys still
> alive?
> 
> Jeremy McNamara
> 
> 
> _______________________________________________
> PreViking-devel mailing list
> Pre...@li...
> https://lists.sourceforge.net/lists/listinfo/previking-devel

[PreViking-devel] Alive?

[Jeremy M. <jj...@in...>]

I haven't heard anything from this list latetly... Are you guys still
alive?

Jeremy McNamara

[PreViking-devel] announcement service

[Abdul-Wahid P. <aw...@gr...>]

I am making some changes to the announcement service that will extend 
the existing basic functionality of playing one prompt in a cycle to 
having a menu system with possible adverts included.

These are the requirements I came up with.

	
1. Should optionally be able to play an advert from a URL.
2. Should be able to play a configurable welcome message.
3. Should be able to play a configurable main menu that allows the user 
to select options.
4. Eight configurable sub-message should be available through the menu 
selection.
5. Complete billing should be available through the pvInfoServer billing 
interface in-line with the Open Telecoms billing spec.
6. Administrators should be able to authenticate through a PIN (checked 
by the billing server).
7. Administrators should be able to re-record the message on-the-fly.

[PreViking-devel] capi driver

[Abdul-Wahid P. <aw...@gr...>]

I have now got the CAPI driver into a stable state (at last *sigh*). 
There are a couple of things that I haven't finished though.

1. the capiRecordVoice function needs to be cleaned up a bit.
2. DTMF key press doesn't stop voice prompt from being played.
3. Early B3 connect - I am going to wait on this because I can't get it 
working and I can't see why. The early B3 connect allows PreViking to 
get the data blocks off the line before the call is actually connected. 
This would be useful for listenning to ringing tones and other 
announcements from the network that are played during the alerting stage 
of call setup. I will try to implement the early B3 connect in a 
standalone package and if/when I get it working I will merge it into the 
PreViking source tree. That is going to be done in 0.5.0 though.

I have also implemented the failed call logging functionality in the 
CAPI driver that Zaheer added to the PreViking core. The CAPI driver 
logs the CAPI disconnect code which is a hybrid containing the Q931 
disconnect code.

Anyone who used any previous versions of the CAPI driver should note 
that I have implemented a bit reverse function for the audio. This 
allows the capi to play straight a-law files rather than the horrible 
reversed-bit alaw files it was playing before. I also put a Perl script 
into the contrib directory which will convert U-law files to A-law 
(using Sox - I'm not that clever ;) )

See ya,

Abdul-Wahid

[PreViking-devel] fixed memory leak and potential memory corruption in 0.5.0 branch

[Zaheer M. <za...@gr...>]

Hi

I have fixed a memory leak and potential memory corruption in
pvPlaceCall in telephony.c, and have committed to the 0.5.0 branch.

Regards

Zaheer

[PreViking-devel] Async model parameters

[Zaheer M. <za...@gr...>]

Here is a draft of the commands and the parameters.

Command: PV_ASYNC_COMMAND_PLACECALL

Parameter name: toaddress
Parameter desc: The address to place call to
Parameter name: fromaddress
Parameter desc: The address the call is from

Command: PV_ASYNC_COMMAND_ANSWERCALL

Parameter name: answermethod
Parameter desc: RING | AUDIO
Parameter name: numrings (optional, only if answermethod=RING)
Parameter desc: number of rings to answer after

Command: PV_ASYNC_COMMAND_REJECTCALL

Parameter name: rejectmethod
Parameter desc: RINGFOREVER | BUSY | AUDIO

Command: PV_ASYNC_COMMAND_DISCONNECTCALL

Parameter name: disconnectcause (optional, default = normal disconnect)
Parameter desc: Maybe use Q931 disconnect cause byte

Command: PV_ASYNC_COMMAND_PLAYAUDIO

Parameter name: audiosource
Parameter desc: RTP | BUFFER
Parameter name: location
Parameter desc: for RTP, an address of the form "ipv4:10.0.0.1:448"
                for BUFFER, pointer to the memory address of the buffer
Parameter name: encoding
Parameter desc: MULAW | ALAW | PCM | etc......
Parameter name: bitrate (for PCM)
Parameter desc: 44100 | 22050 | 8000 etc.
Parameter name: depth (for PCM)
Parameter desc: 8 | 16 (num bits per sample)
Parameter name: signed (for PCM)
Parameter desc: true | false

Command: PV_ASYNC_COMMAND_RECORDAUDIO

Parameter name: audiosink
Parameter desc: RTP | BUFFER
Parameter name: location
Parameter desc: for RTP, an address of the form "ipv4:10.0.0.1:448"
                for BUFFER, pointer to the memory address of the buffer
Parameter name: encoding
Parameter desc: MULAW | ALAW | PCM | etc......
Parameter name: bitrate (for PCM)
Parameter desc: 44100 | 22050 | 8000 etc.
Parameter name: depth (for PCM)
Parameter desc: 8 | 16 (num bits per sample)
Parameter name: signed (for PCM)
Parameter desc: true | false
Parameter name: silencetimeout
Parameter desc: number of milliseconds of silence

Command: PV_ASYNC_COMMAND_GETDTMFSTRING

Parameter name: maxdigits
Parameter desc: maximum number of digits required
Parameter name: firsttimeout
Parameter desc: number of milliseconds to wait for first digit
Parameter name: intertimeout
Parameter desc: number of milliseconds to wait for every intermediate
digit
Parameter name: termdigits
Parameter desc: what terminating digits e.g. #

Command: PV_ASYNC_COMMAND_STARTVOICESWITCH

no params, just list of channels

Command: PV_ASYNC_COMMAND_STOPVOICESWITCH

no params, just list of channels

Extra commands that I had forgotten: 
PV_ASYNC_COMMAND_STOPPLAYAUDIO
PV_ASYNC_COMMAND_STOPRECORDAUDIO


Regards

Zaheer

[PreViking-devel] driver async model + test cases

[Zaheer M. <za...@gr...>]

You may have noticed that the CVS has branched.  A 0.5.0 branch has been
created which is solely there for the remainder of 0.5.0 to be done.  In
HEAD, I committed the driver async model framework and now I have
committed a test case for it.  I have used cUnit which is at
http://people.codefactory.se/~spotty/cunit/ and using this I noticed
some bugs in the code which I have also committed fixes for.

Another thing I committed was an autoconf/automake cleanup which now
allows PreViking to be compiled okay on RH 7.2.

Now the async model framework is complete, I am going to start working
on the parameters for the commands I mentioned in my previous email.

Regards

Zaheer

[PreViking-devel] asynchronous model for the drivers

[Zaheer M. <za...@gr...>]

I have just completed the asynchronous model framework for PreViking
drivers.  This framework is driver-independent and is in the
drivers/common directory of the CVS.

Using this framework, porting drivers to support the asynchronous model
is trivial.

What is required in the driver is one function of the form:

typedef void (*pvAsyncDriverCommand)(struct pvChannel*, 
				     struct pvAsyncModelCommand*);

where pvAyncModelCommand is:

struct pvAsyncModelCommand
{
  gint type;
  GHashTable *params;
  struct pvAsyncModelChannel* chan;
};

type is an integer specifying the type of the command.
params is a hash table with the parameters that the command requires (I
will define these soon, on a per command basis).
chan is unimportant and can be ignored by the driver.

The function would have to start the execution of the command
represented by the pvAsyncModelCommand, and that is all so here is an
example function:

void dummyDriverCommand(struct pvChannel* pvchan,
                        struct pvAsyncModelCommand* command)
{
  switch (command->type) {
	case PV_ASYNC_COMMAND_PLACECALL:
             	 	dummyPlaceCall(pvchan,(gchar*)g_hash_table_lookup(
					command->params,"dialnumber"),
		               (gchar*)g_hash_table_lookup(
					command->params,"callingnumber"));
	break;
	....
  }
}


More details can be found by asking me or looking at the code.

Zaheer

[PreViking-devel] asynchronous driver interface + implications

[Zaheer M. <za...@gr...>]

Sorry, I cannot wait for the rest of 0.5.0 to be complete (capi cleanup
+ test of failed calls).

So I have started working on some of the 0.5.1 functionality.

0.5.1 is bringing an optional asynchronous driver interface into the
driver functions.  It's also allowing services to receive events.

The current threading model is that the synchronous command runs on the
thread that calls it.  For asynchronous commands, however this cannot
happen.  Therefore I propose that worker threads are created on driver's
initialisation, one thread for each channel.  These threads would then
be given "tasks" by the calling of the call control and dsp commands
asynchronously.  On start of tasks, a "doing" event would be sent to the
PreViking layer, and on completion a "done" event would be sent.

The extra events I have considered are:

// Events due to async behaviour
#define PV_TELEPHONY_PLACINGCALL 40
#define PV_TELEPHONY_ANSWERINGCALL 41
#define PV_TELEPHONY_REJECTINGCALL 42
#define PV_TELEPHONY_PLAYINGVOICE 45
#define PV_TELEPHONY_PLAYINGVOICE_DONE 46
#define PV_TELEPHONY_RECORDINGVOICE 47
#define PV_TELEPHONY_RECORDINGVOICE_DONE 48
#define PV_TELEPHONY_VOICESTREAMS_CONNECTED 49
#define PV_TELEPHONY_VOICESTREAMS_DISCONNECTED 50
#define PV_TELEPHONY_PLAYINGDTMF 51
#define PV_TELEPHONY_PLAYINGDTMF_DONE 52
#define PV_TELEPHONY_RECODINGDTMF 53
#define PV_TELEPHONY_RECORDINGDTMF_DONE 54

The call control and dsp commands would have a flag specifying whether
the command is asynchronous or synchronous.

The doubtful thing is, whether synchronous and asynchronous commands
could be run on the same channel in the same session without causing
problems.

Regards

Zaheer

[PreViking-devel] BayonneDB CVS has been moved...

[David S. <dy...@os...>]

To savannah.gnu.org, it is currently being updated as a seperate module in
Bayonne cvs.

[PreViking-devel] BayonneDB changes proposed

[David S. <dy...@os...>]

One area I am looking to improve BayonneDB is in setup and configuration.
My current thought is to make BayonneDB automatically scan for plugins at
startup (and for Bayonne to do the same for most plugin types).

Another change would be a standardized install and removal method for
database tables that underly an active or changed BayonneDB configuration.
I have looked at how phpgroupware does this, and I am thinking of
something similar, where one can have a create_modulename.[db]sql and
remove_modulename.[db]sql and have this somewhat automated, or at least
easy to perform.  This should make it easier to deploy applications that
can be packaged for and require BayonneDB maintenance operations to be
performed.

David

[PreViking-devel] Failed call logging + other ideas

[Zaheer M. <za...@gr...>]

I have committed the failed call logging both in PreViking and in
pvinfoserver (which will be released soon, simultaneously with PreViking
0.5.0).

Failed call logging logs all failed calls, and the message is sent over
the network to the failed call logging server (pvinfoserver can act as a
failed call logging server).  It follows the syntax and style of the
number, routing and billing servers.

The message sent from PreViking is as follows:

C <uniqueid> FAILEDCALL session=<sessionid> calltime=<callts>
carrier=<carriername> number=<diallednumber>
hwreason=<hardware_reason_code> driverreason=<driver_reason_code>
switchreason=<switch_reason_code> switchname=<switchname>

The response from the server is (assuming success):

200 result=Ok

I will explain more later.

Regards

Zaheer

[PreViking-devel] rare channel blocking

[Zaheer M. <za...@gr...>]

I believe I have fixed a potential channel blocker.  There was a
possibility that the channel was in the process of having a call being
placed and that channel could have been attempted to have been taken by
another session.

Hopefully this can be tested soon.

Regards

Zaheer

[PreViking-devel] "standardised" method of doing number translation

[<za...@gr...>]

Aymeric

Correct me if I am wrong, but the number translation we had proposed of
sending a set of tags such as:

TRANSLATEADDRESS address=02081234567 srcformat=uk destformat=carrier carrier=BT

which may have returned:

200 translatedaddress=442081234567

could be done by dynamic generation of a URL and sending to a SIP
redirect server:

I guess the URL for the above example could be:

uk-...@bt...

and PreViking would send:

INVITE uk-...@bt...

The redirection proxy would return a 302 Moved with the redirection
address as:

442...@ps...


Am I barking up the wrong tree or is this a valid use of SIP?

The dynamic number translation would be used by PreViking to figure out
what to dial.

A good example of where it may be useful is, lets say you have a calling
card service in the UK.  You want the users to dial a number as if they
are in the UK, but the carrier you may use to actually place the call is
based in USA so expects a number as if dialled from the USA.  Some sort of
number translation is required, especially if there are many carriers
requiring different dialling methods.

Regards

Zaheer

[PreViking-devel] monitor update

[<za...@gr...>]

I have been busy here streamlining the monitor so it uses the session
linked list rather than storing its own data seperately.  I have also
added a few commands to the monitor.  Details are below.

I believe it should be restructured even more to use a tagged parameter
list for each command and reply (and hence a lot less commands).

Also what is missing is commands for retrieving overall channel status,
which I will add in once the commands have been tagged etc.

But this change should go into 0.5.0 (which has been delayed I guess by
the small changes AW did to the CAPI driver).

I have also finished the last remaining thing for pvPlaceCall (the actual
sending of extra options passed through).  I have also removed the hack
that got the access number from the monitor's store.

Removal of the hack meant that the services have to pass the access number
as an extra option to pvPlaceCall, so this has been done also.

Zaheer
--

The commands are as follows:

Monitor commands

All are preceeded by: "GET "

STARTTIME

returns the start time of server in human readable format


CURRENTTIME

returns the current time of server in human readable format


MAXSESSIONS

returns the maximum number of simulataneous sessions, so far encountered


TOTALSESSIONS

returns the total number of sessions encountered


CURRENTSESSIONS

returns the current number of running sessions


SESSIONID <session_index>

returns the session id of a given session index (in range
1..CURRENTSESSIONS)


SESSIONNUMCHANNELS <session_id>

returns the number of channels for given session id


CHANNELSTATE <session_id> <channel_index>

returns the state (PreViking state code) of the given channel index of
given session


CHANNELCARRIER <session_id> <channel_index>

returns the carier of the given channel index of given session


CHANNELCALL <session_id> <channel_index>

returns 1 if there is an active call on given channel index of given
session


CALLDIRECTION <session_id> <channel_index>

returns I (incoming) or O (outgoing) as direction of active call on given
channel index of given session


CALLADDRESSIN <session_id> <channel_index>

returns the calling address of active call on given channel index of given
session


CALLADDRESSOUT <session_id> <channel_index>

returns the dialled address of active call on given channel index of given
session


CALLSTARTTIME <session_id> <channel_index>

returns the starttime in human readable format of active call on given
channel index of given session


CALLDURATION <session_id> <channel_index>

returns the duration in seconds of active call on given channel index of
given session


SESSIONSTART <session_id>

returns the starttime in human readable format of given session


SESSIONDURATION <session_id>

returns the duration of given session


SESSIONSERVICE <session_id>

returns the service name of given session


SESSIONAGENT <session_id>

returns the agent name of given session

QUIT

closes TCP connection

[PreViking-devel] Re: Perviking and AG2000

[<za...@gr...>]

Hi

You should join the previking-devel list:
http://lists.sourceforge.net/mailman/listinfo/previking-devel


On Sat, 14 Jul 2001, Demo wrote:

> Dear sir,
> 
>             I want to know about previking and NMS AG2000. Now I have a AG2000 i want to setup it for VoIP.
> I never experience in telephony system. But I am a linux developer. I have some quesion to you.
>             1. in you howto 
>             ./configure if you have an NMS card and ctaccess installed
> 
>               What is CT Access ?.

CT Access is part of Natural Access.  You can download Natural Access for
RedHat 6.2 from NMS's web site.  If you go to support, software and
documentation and then search for products by OS and choose Linux, you'll
be able to download Natural Access 2001-1 Beta for Linux.

Once you have it installed and working, do: ./configure --enable-nms from
inside the previking intsall dir.

Regards

Zaheer Merali

Re: [PreViking-devel] route server and number translation

[<za...@gr...>]

This is a good idea, ideally for every route carrier the actual number to be 
dialled (i.e. the translated number) should be returned.  However this is 
going to make the return message a bit more difficult to deliver.  Also there 
is reason to do more generic number translation, like in the calling card 
service:

when the caller dials a number, we want that number to be in different 
formats for different agents possibly and a way of translation to the number 
format used for billing...

a message like:

TRANSLATEADDRESS address=0845123456 sourceformat=UK destformat=carrier 
carrier=carrrier_1

should return:

translated_number=448456203031

Something like this, anyway.

Any comments

Zaheer




so possibly

Abdul-Wahid Paterson <aw...@gr...> said:

> 
> I was just thinking about changing the way that PreViking does number 
> translation. (currently PreViking only translates UK numbers *cough* 
> *cough*). I think that we idealy need something dynamic and may be it 
> could use the routing server as the routing server already knows about 
> the carriers.
> 
> Also, this might later be useful for other types of number/address 
> translation. For example, we might be able to translate SIP addresses to 
> PSTN address so that we could have a SIP<--->PSTN gateway.
> 
> Regards,
> 
> Abdul-Wahid
> 
> 
> _______________________________________________
> PreViking-devel mailing list
> Pre...@li...
> http://lists.sourceforge.net/lists/listinfo/previking-devel
> 



-- 

[PreViking-devel] route server and number translation

[Abdul-Wahid P. <aw...@gr...>]

I was just thinking about changing the way that PreViking does number 
translation. (currently PreViking only translates UK numbers *cough* 
*cough*). I think that we idealy need something dynamic and may be it 
could use the routing server as the routing server already knows about 
the carriers.

Also, this might later be useful for other types of number/address 
translation. For example, we might be able to translate SIP addresses to 
PSTN address so that we could have a SIP<--->PSTN gateway.

Regards,

Abdul-Wahid

[PreViking-devel] internet initiated callback

[<za...@gr...>]

After the talk at the LSM in Bordeaux, AW and myself started work on
allowing callback to be initiated by the Internet than just by the
dialling of a number.

I have completed the work, however it hasn't been tested.  Also, it should
really be tested too.  This is something that can be made into a "web
service" and initiated by SOAP.

Regards

Zaheer

Re: [PreViking-devel] New release schedule

[<za...@gr...>]

On Thu, 14 Jun 2001, Abdul-Wahid Paterson wrote:

> Zaheer and I had a long meeting last night to discuss the progress of 
> PreViking and to discuss a new release schedule. Most of the meeting was 
> spent reading slashdot, eating MacDonalds and on my part playing Quake. 
> Anyway, we did manage to agree on the following schedule.
> 
> 
> 0.4.9  - move many of the command line arguments to the
>           main configuration file because the command line
>           is getting too long. (Abdul-Wahid)
>         - finish migration to use pvNewPlaceCall (Abdul-Wahid)
>         - dmalloc all services (Zaheer & Abdul-Wahid)

the only thing not done is the dmalloc check for potential memory
corruption.

> 
> 0.4.10 - move billing server to use UDP rather than (Abdul-Wahid ?)

This is done as well as the number server and the routing server.

> 
> 
> 0.5    - CAPI driver completion (Abdul-Wahid)

From what you've told me this is imminent.

>         - Services to have initialse, reload and destory functions
>           (Zaheer)

This is complete and working.

>         - Monitor to display all calls for a session
>           (Abdul-Wahid)

This can now be done, as the session management stuff I have done has all
this information very easily retrievable.

>         - session should be able to be started by other means
>           than an incoming call (Abdul-Wahid)

This can now be done.

>         - fix number translation (currently only works of UK ;) )
>           (Abdul-Wahid)

Maybe this should be pushed back to a later release

> 
> 0.5.1  - introduction of event mechanism for services
>           (Zaheer & Abdul-Wahid)

This won't be too difficult so lets move the number translation stuff to
this release.
> 
> 0.5.2  - asynchronous audio playing
>           (Zaheer & Abdul-Wahid)

This requires the event mechanism from 0.5.1.

> 
> 0.5.3  - call centre to handle multiple queues
>           (Abdul-Wahid)

This can be done now, maybe add completion of H323 driver here.

>         - ringthru service
>           (Abdul-Wahid)
> 0.5.4  - proper audio streaming
>           (Abdul-Wahid)
>         - interface to media server
>           (Zaheer)

This is going to be the most interesting release...


Zaheer

> 
> 0.5.x tree to continue as bug fixes and enhancements to existing 
> services. Also, work on the CallXML implementation to slowly add 
> functionality.
> 
> 
> 0.6     - Full call XML support
>          - Full switching support
>          - Full audio streaming support
> 
> 
> The CORBA stuff originally planned (and half finihsed) which was going 
> to be in 0.5.0 will have to be pushed back. This decision has been made 
> due to the amount of time that Zaheer and I have on our hands and our 
> current business requirements that obviously have to be satisified. It 
> doesn't mean that it is off the agenda altogether. Rather it might come 
> back in the 0.7.x series or the 0.9.x series. This will be decided after 
> the release of 0.6
> 
> Regards,
> 
> Abdul-Wahid
> 
> 
> 
> 
> _______________________________________________
> PreViking-devel mailing list
> Pre...@li...
> http://lists.sourceforge.net/lists/listinfo/previking-devel
> 

Re: [PreViking-devel] Session Management

[<za...@gr...>]

On Thu, 5 Jul 2001 za...@gr... wrote:

> I know this was meant to go into a later version of 0.5, but I thought it
> too important not to be done.  I have committed into HEAD, session
> management functions to handle creation of sessions, addition and removal
> of channels to/from session, and destruction of sessions.  This now allows
> sessions to be started without incoming call.  I have changed the releavnt
> places to use the new session management functions, and so it is now
> integrated in.

After reading our 0.5.0 release functionality description, it is actually
required...so good thing I did it now.

> 
> Beware, it hasn't been tested yet.
> 
> What I haven't implemented yet is the pvTransferChannelToSession function
> that would transfer a channel from one session to another with a
> precondition that the sessions must be of the same service.  This is
> needed for things like the callcentre service, and would also be required
> for services like a conference call service where the participants ring in
> to become part of the conference.
> 
> Hopefully I can get that done tomorrow before departing to France.

Well it is done now.


> 
> Zaheer 

Zaheer

[PreViking-devel] Session Management

[<za...@gr...>]

I know this was meant to go into a later version of 0.5, but I thought it
too important not to be done.  I have committed into HEAD, session
management functions to handle creation of sessions, addition and removal
of channels to/from session, and destruction of sessions.  This now allows
sessions to be started without incoming call.  I have changed the releavnt
places to use the new session management functions, and so it is now
integrated in.

Beware, it hasn't been tested yet.

What I haven't implemented yet is the pvTransferChannelToSession function
that would transfer a channel from one session to another with a
precondition that the sessions must be of the same service.  This is
needed for things like the callcentre service, and would also be required
for services like a conference call service where the participants ring in
to become part of the conference.

Hopefully I can get that done tomorrow before departing to France.

Zaheer 

[PreViking-devel] previking and cvs branching

[Abdul-Wahid P. <aw...@gr...>]

The PreViking CVS has been branched from the 0.4.10 release. Upto now I 
have tagged all of the PreViking releases in the form of PV_X_Y_Z where 
X, Y and Z are the version numbers for PreViking. For the 0.4.10 branch 
I have make a seperate tag PV_0_4_10-BRANCH which is the branch point.

The reason for this is that we are now working on the 0.5.x branch 
(hopefully I can release 0.5 later this week) but 0.5.x is considered 
development code. 0.4.x will remain the stable code. If there are 
necessary bug fixes to the 0.4.x code tree they will be put onto the 
PV_0_4_10-BRANCH.


To make things easier I will list a few uses of cvs to save you guys 
searching on how to do things yourselves.

To check out the 0.4.10 branch

cvs co -r PV_0_4_10-BRANCH

or if you are already on the head you can do

cvs update -r PV_0_4_10-BRANCH

To change back to the HEAD of the cvs do

cvs update -A

To see the diff of a file between the head and the branch do

cvs diff -r PV_0_4_10-BRANCH

To join (merge) a file from the branch to the head do (whilst you have 
the HEAD checked out)

cvs update -j PV_0_4_10-BRANCH filename.c

Then commit the filename.c in the usual way

cvs commit filename.c



I hope that helps.


Abdul-Wahid