[help] Asterisk, softphone and Terminal Services


#1

Does anybody know if it is possible to run a softphone connected to Asterisk, from a thin-client, using Windows Terminal Services.

Thanks


#2

I don’t see why not. Although i know nothing about windows terminal services and associated thin clients. (I do have some experience with LTSP though, which i guess is similar).

The main thing it depends on, i suppose, is where the softphone is actually running - i.e., on the client (probably not) or on the server. If the phone is running on the server, then it must have an audio connection to the client - which, presumably, it would have.

An important issue here though - if the phone is running on the server - is that you’ll probably only be able to run one phone. This is because if you try and run more than one phone, they will all want to listen on the same SIP port (which they can’t do) - unless you can configure the phone differently for each user, which makes things complicated.

So if you’re hoping to have multiple users in an office or something all using softphones in this way, you’re likely to run into serious problems.


#3

I have trouble using the thin-client microphone. For some reason I can’t get terminal service to use it.

What do you mean by more than one phone. I would expect that every client, every instance of a softphone, uses their own tcp-ports. Isn’t it so that, when logging on to Asterisk the softphone gets their own tcp-port for communicating?

Thanks


#4

For a start, they use UDP, not TCP. Well, some phones may be able to use TCP as well, but Asterisk doesn’t support SIP over TCP.

If you’re talking about SIP phones, then the standard port is 5060 (the standard port for IAX2 is 4569) - most (some? all?) softphones allow you to configure this. You would have to configure a different port for each user - or they will all try and listen on 5060, which isn’t possible.

Sounds like you need to do a bit of reading before trying to implement this stuff. You’ll find a lot of information at

voip-info.org


#5

Ports are not the problem. You could run multiple clients on one machine. They would create their individual sockets to send requests to the server on port 5060. In other words… replace “tcp-port” with “socket” and you’re right there.
Having said that, a softphone might still run only in one instance on a machine. They certaintly ought to limit to one instance in a session, because the softphone implementation should assume that there’s only one set of mic and speakers on a desktop computer. It might be different with terminal services or Citrix. Even if multiple softphones start, you might get problems routing audio between the terminal running the thin client through to Asterisk, via Terminal Services or similar. Check it out…
BTW, I would not offer this to real users. I did not find the softphones I tested - X Lite on XP and OS X - suitable for daily use, and that’s even without the complication of Terminal Services.


#6

I don’t quite understand your logic here. If Asterisk wants to connect to the softphone, because it wants to route a call to it, it sends SIP packets to port 5060 on that host. If there are two softphones running on the same host, they both have to listen on 5060 (which can’t be done) - unless they’re individually configured to listen on different ports. RTP ports would be the same.

It’s like trying to run a phone and Asterisk on the same machine - it can be done, but not unless you change the port that the phone (or Asterisk) listens on.

If you try and run two softphones on the same machine, the first one you start will work ok, but when you try and start the second one it will complain that it can’t use the socket and will probably just die.


#7

[quote]I don’t quite understand your logic here.[/quote] I have to admit it’s backwards and academic. What I am trying to say: If the designer of a softphone could make the assumption that a desktop computer had multiple sets of mic/speaker to use as resources, TCP or UDP would not be in the way of running multiple softphones on a machine.