Caller ID / ADSL (1 Viewer)

[samedney]

Can something like this be implemented in Media Portal?

http://www.beststuff.co.uk/tv_messenger_plus.htm

I see someone is already working on a plugin, but how would something like this work if you use an ADSL modem or router, like I do?

My setup consists of an ADSL modem connected to a Wireless router. I then have a file server which stores all the media files (avi/mp3 etc), and a laptop under the TV running Media Portal.

How could I get the caller ID to display on any machines currently running media portal - ie. some kind of broadcast...?

I suppose having a modem in the server, attached to the standard phone socket could pick up the number....

Im in the UK and BT support caller ID.

 

[samuel337]

Using an ADSL modem or router makes no difference to the setup. The callerID is 'broadcasted' to all phones in the house.

Currently, the plugin works by reading the caller ID signal from the modem card when a call comes in.

From your post, I'm thinking that you want to have one modem connected to the phone line and when a call comes in, the caller ID is broadcasted to all MP machines.

I don't think this networking caller ID thing is possible with the current plugin...

You can play with the current version here though:
http://sourceforge.net/tracker/?group_id=107397&atid=647927

Sam

 

[|Lars|]

aehm... the caller id is broadcasted to all phones yes. but not over the dsl-modem or router.. because you have a spliter that split pots before your modem. so you need a isdn card to get your caller id.

i saw a post some days ago that somebody is working on a caller id plugin.-> klick me
CU

Lars

 

[samuel337]

aehm... the caller id is broadcasted to all phones yes. but not over the dsl-modem or router.. because you have a spliter that split pots before your modem. so you need a isdn card to get your caller id.

i saw a post some days ago that somebody is working on a caller id plugin..... just search for it.


CU

Lars

Um...Lars you're right about the adsl filter splitting up the POTS and ADSL signal so therefore the ADSL modem doesn't receive callerID messages, but any normal 56k modem can read the callerID message if it receives the POTS signal - you don't need a ISDN card for that.

Sam

 

[|Lars|]

but any normal 56k modem can read the callerID message if it receives the POTS signal - you don't need a ISDN card for that.

yes.. but here in germany most ppl have isdn... sure new modems will get callerID 2

CU

Lars

 

[samedney]

Yes, as I thought. I think I have an old modem around here somewhere, which could be set up on the server (or on the main PC I guess).

This would have to be attached to an app, which would then broadcast the caller ID as it came in. It could check it against a database etc too.

Any machines running the correct plugin on either XBox Media Center, or Media Portal could capture this 'Broadcast' and pop up the details on the screen.

Writing an app to broadcast the number as it comes in is pretty simple. I could do it in VB.net. Someone else would need to do the media portal bit, as I dont know much about C# as yet.

Perhaps for starters, I should try writing a tool which broadcasts the signal, and another tool which pops up the broadcast on any PC running it. Then, I could pass on that code, so it could be used in MP?

Is this what someone is working on already, or is it just for a local phone / modem connection? Im not about to go back to using dial up any time soon!

Let me know if this will be of use to anyone.

 

[samuel337]

The beauty of .net is that all the .net languages work with each other, so you can use VB.NET to write a MP plugin, even though MP is written in C#.

Assuming that the guy who wrote the local version of the caller ID plugin included the source code, you could use his code as a basis for your MP plugin (not sure which language he used though)...

I'm wondering how you're going to do the broadcasting bit... .net remoting?

Lars:
Sorry about that then, I guess us people in aust are always a bit behind the times ;-)

Sam

 

[|Lars|]

Sorry about that then, I guess us people in aust are always a bit behind the times ;-)

eheh... no problem

 

[samedney]

OK. I have code for picking up the caller ID already, in a VB 6 app I wrote a long time ago. I am still not exactly confident using .Net so perhaps a little help is needed here.

What is the best method for Media Portal to pick up some values?

Options could be (starting with the most simple)...

1. File on disk. Media portal could check if exists. Would require MP to actively and constantly search for file. Not really ideal.

2. TCP. Could be setup on server to only send a packet to specific IP's.

3. Web Services. (Is there a web service running in MP for anything already?)

4. .Net Remoting. I have no idea what this is, so if you think it suits, let me know.

 

[samuel337]

OK. I have code for picking up the caller ID already, in a VB 6 app I wrote a long time ago. I am still not exactly confident using .Net so perhaps a little help is needed here.

What is the best method for Media Portal to pick up some values?

Options could be (starting with the most simple)...

1. File on disk. Media portal could check if exists. Would require MP to actively and constantly search for file. Not really ideal.

2. TCP. Could be setup on server to only send a packet to specific IP's.

3. Web Services. (Is there a web service running in MP for anything already?)

4. .Net Remoting. I have no idea what this is, so if you think it suits, let me know.

I agree that method one is not really ideal, but .net does provide a very nice filesystemwatcher class that does the 'watching' work for you.

Web services - there is a web service running in MP if you install the webscheduler plugin. This method is definitely workable - your callerID detection app would call the web service when a call is detected, passing on the information. The web service would then in turn notify MP.

TCP and .net remoting - .net remoting is basically TCP, but more advance and programmatically-sided. All .net remoting is is that you can 'remote' a DLL file so that an external app can call on the DLL file which is already running. What's really happening behind the scenes is that .net turns the DLL into binary or text, transports it to the caller, turns it back into a DLL, the caller makes the call, and .net again converts it to binary or text, transports it back to the 'server' or the running instance of the DLL, converts it back into a DLL and executes the command called. It can do the transporting over TCP or HTTP.

I'm sure all that sounds confusing - for simplicity, think of .net remoting as a like a web service except without the web service web interface and all the hosting things that come with it. It is a .net only technology, and performance-wise its better than web services.

If you're already familiar with transporting messages over TCP, then by all means do that - I don't know much about that.

Anyway, its up to you which way you go.

Sam