Hi all,

Just want to comment that if you are goint to use X just to run the Elastix client, you might not need to install a desktop enviroment (gnome, kde, xfce. If I am not wrong when install the X server you would have twm as window manager.

So when you install the x server you would have a lazy graphical interface with an graphical comand line from where you could lounch skype.

Other option could be to just install skype and the needed libraries on the server and install X on a second machine. Then you could use "ssh -X" to run skype graphically on a second machine. Might be more complicate but just another option.

Regards,

Rafael

Stupid rant removed.

Ok, I have struggled with this for more than 8 hours already and finally I think I have a solution for minimal installation.

I have a CentOS 5.2 minimal installation with pure Asterisk running on it, no freepbx. So when I followed instruction on NV, it didn't work for me ,something was still missing. With Dicko's help on vncserver, I managed to find out what packages are still missing for minimal installation that doesn't require Gnome, KDE, or even xfce.

Here it goes:

yum install Xorg (This is required to run skype under X11 environment)
yum install xorg-x11-font* (This will install all the fonts for X server, and eliminate feature error when you run skype from Xvfb)
yum install vncserver (xVnc is needed for first time configuration of your skype)

I am runnnig all this on a remote server, so it is extremely helpful to be able to see my screen through vncserver and configure skype for the first time. Once I am done activating skype for the first time, I don't really need to use vncserver to lunch skype anymore(unless for trouble shooting). And with my minial installation, there is no "initx" command to run as instructed on NV. So here is how to make my version work:

Xvfb :2 & (This will create a virtual X11 environment on display 2)
export DISPLAY=:2
skype & (this will run skype in the background)

This is it for most people, but I am still struggling with one issue. I don't have a sound card on my remote server, but in order for skype to send calls out or receive call, I need to assign a sound device in the skype's sound configuration. Does anyone here know if I can setup a "virtual sound device" just like how Xvfb is providing "virtual X environment". I have been searching all around but haven't find instruction teaching how to implement a virtual sound device to the linux system yet.

I know I said I was going to hang this up but I do have one more thing to report. Last night I had the system so screwed up (had no idea what was running) that I rebooted it. I remembered that I had set the runlevel to run X on startup but didn't actually know what, if anything, that would do. My earlier message was written this morning after trying (unsuccessfully) to start the vncserver via an SSH connection, then connect using a VNC client.

Well, I had someone assisting me again this afternoon and he said when he turned on the console display it looked completely different than it did yesterday. So I knew Xwindows was running, so we did a bunch of tests, among which was starting the vncserver from a console window. Once we did that, I was able to connect using a VNC client. Obviously it's not very useful if I can't start the VNC client remotely, but then again if we ever get this working I shouldn't have to use VNC very often.

Some observations:

We started Skype (using skype &) then siptosis. After that, on the FIRST incoming call, everything works except incoming touch tones. If I set the incoming route to point to an extension, it will ring the extension and we have two-way audio, and if the skype user toggles the dialpad and clicks on touch tone buttons they can be clearly heard, but they will not trigger the IVR, if I route the call there! I'm suspecting a volume level problem since the tones seem much higher in volume than normal.

However if I try to call back, that's when the weird stuff starts happening. It turns out that the biggest problem is this: The Skype client opens a window each time there is an incoming call (those of you familiar with Skype know what I'm talking about), but Xwindows (using the default display manager twm) only displays a "grid" pattern instead of the window. Until you take the mouse and click on the grid, that window blocks any further communications (a subsequent incoming call will show "User not online" ). This is true whether at the local console or using VNC. We we need to figure out is how to get Xwindows to just display the window. It's strange because it will display the first little popup notification with no problem, but it's the window that's actually up while the call is in progress that is causing the problem. As long as we click on that window to activate it, it will go away by itself when the call is finished, but if no one clicks on it it just hangs around and blocks further communications. I'm thinking this is an Xwindows issue but don't have a clue how to resolve it.

The other issue we had is outgoing calls not working at all. That's a somewhat lower priority but I can tell you that when the call is attempted it prints a line like this
2009-02-25 19:29:38,414 incoming sip call from "User Name" <sip:345@asterisk.server.address> callee=<sip:echo123@127.0.0.1:5070>
2009-02-25 19:29:38,437 handleSipCall - rejected call
But no indication WHY it's rejecting the call. However, when SipToSis is launched, it prints out the following:
Launching SipToSis
2009-02-25 18:37:53,738 Starting SipToSis v20090214
2009-02-25 18:37:53,741 os=Linux arch=i386 ver=2.6.18-53.1.19.el5
2009-02-25 18:37:53,742 javaVer=1.6.0_12 - Sun Microsystems Inc.
2009-02-25 18:37:53,867 Codec Error: GSMTRI - Codec won't instantiate - local.ua.sscodecs.SSCodec_GSMTRI
2009-02-25 18:37:53,868 Codec: GSMTRI not loaded.
2009-02-25 18:37:53,986 Available Codecs: PCMU(0),PCMA(8),iLBC(98),speex(97)
2009-02-25 18:37:53,987 DTMF rfc2833(101)
2009-02-25 18:37:53,988 initSkype - If stuck, check Skype online & API auth
2009-02-25 18:37:54,097 SkypeVer:2.0.0.72
2009-02-25 18:37:54,106 SkypeUserId:skypeuser
2009-02-25 18:37:54,119 Config - skypeClientSupportsMultiCalls:false concurrentCallLimit:2
2009-02-25 18:37:54,120 SipToSis contact_url=<sip:SkypeCaller@127.0.0.1:5070>
2009-02-25 18:37:54,121 RTP Ports: 63200-63202 Local Skype Ports: 64432-64435
2009-02-25 18:37:54,270 WAITING FOR INCOMING CALL
2009-02-25 18:37:54,283 Domains=
WARNING: file "users.db" not found: created new empty DB
2009-02-25 18:37:54,296 WAITING FOR INCOMING CALL
Note that next to last line - I'm not sure where it is looking for "users.db" or what is supposed to be in it, but I do wonder if that's what is blocking outgoing calls. EDIT: It isn't - or maybe it could be part of it, but it turns out there's an easy workaround. You have to go to /siptosis/SipToSkypeAuth.props and note that the last line is: *,*,127.0.0.1,calleeid - if you change that to *,*,*,calleeid it works, although if you do that you want to make absolutely sure that port 5070 is not open in your router or firewall for incoming traffic from the world wide Internet. Although I did have one other issue as well - in the Skype client itself, I had to go into Options|Sound Devices and change the Sound Out setting to an actual hardware device instead of Default Device (I just picked the first one on the list). Now outgoing calls do work as long I am quick to click on the "grid" box that pops up in X-windows - that is really the last hurdle to making this somewhat usable. FURTHER EDIT: According to the author of SipToSis, the "users.db message is caused by not turning off the built-in registrar server... This should be turned off for all PBX users." To change that, go into /siptosis/siptosis.cfg and change the is_registrar value to is_registrar=no - and while you're in siptosis.cfg also change the concurrentcalllimit to concurrentcalllimit=1, otherwise the Skype client will try to automatically place one call on hold when another comes in and the first call will be cut off! Edit 6a: NOTE: These changes to siptosis.cfg are included in downloads after March 1, 2009.

So if I do decide to fiddle around with this some more, the one thing I will probably most need to know is, what do I need to do to Xwindows to get it to just display those Skype "call in progress" windows without putting up the grid pattern first (so they will go away at the end of a call, or on outgoing calls, allow the call to begin in the first place)? Edit 2: I've now figured out that these are produced by the default window manager Enlaces ocultos para usuarios no registrados. Inicie sesión o regístrese Aquí, which is described in Wikipedia thusly: "Although it is now generally regarded as the window manager of last resort, a small but dedicated minority of users favor twm for its simplicity, customizability, and light weight

WISEOLDOWL:

I have posted a way to start skype and siptosis without invoking vncserver at the following thread.

pbxinaflash.com/forum/showthread.php?t=3495&page=3

bbhenry wrote:
WISEOLDOWL:

I have posted a way to start skype and siptosis without invoking vncserver at the following thread.

pbxinaflash.com/forum/showthread.php?t=3495&page=3

You beat me to posting a link to your message - that's excellent work there. As I said above I'll probably switch to your method once I have all the kinks out of this, but for now I kind of like being able to see what the Skype client is doing (also, after spending hours trying to figure out a way to do it I sort of hate to just throw all that away even if your way is shorter, better, and uses fewer system resources).

This is just something I threw together. I discovered that with these changes you can get incoming Caller ID from the Skype caller - the way I have it set up, it shows the Skype username in the Caller ID Name field, and "Skype_Caller" in the Caller ID number field (of course, you can change that if it breaks anything). This has been seriously revised from the earlier post that I have deleted.

So if you would like a real trunk to your SipToSis gateway, here's something I threw together specifically for Elastix/FreePBX. I'm not saying it's 100% correct (I did some educated guessing) but at least in limited testing it seems to work as intended:

But before you create the trunk, you need to make a change in /siptosis/siptosis.cfg - look for the (uncommented) line that says passwd=unimportantpassword, change the password to something better (possibly it doesn't matter, but just to be safe), and then add a new line after it (you don't have to add the line if you downloaded the software after March 1, 2009 - it's already included, so just change the password in that case):

passwd=somegoodpassword
from_url="SkypeCaller" <sip: Skype_Caller@127.0.0.1:5060> (DO NOT INCLUDE THE SPACE BEFORE "Skype" )

If you are smart you will resist the urge to uncomment any of the other lines in that section - I tried it and wound up with all manner of headaches, from log entries being generated every 15 seconds(!) to calls that went through with no audio.

Also, make sure you have replaced the string mothership with 75793 in /siptosis/SkypeToSipAuth.props if you have not done so already (I am assuming you are using the Nerd Vittles stuff here).

Restart SipToSis (you may to reboot if you have set it up to start at system startup) and then create a new SIP trunk:

Maximum Channels: 1

Trunk Name: Skype

PEER details:

disallow=all
allow=ulaw&alaw&ilbc&speex
canreinvite=no
context=from-trunk
dtmfmode=rfc2833
host=127.0.0.1
incominglimit=1
nat=never
port=5070
qualify=yes
secret=somegoodpassword
type=peer
username=Skype_Caller
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.255

Remove anything in the USER section, save and apply, and that's all you need in the trunk configuration (probably even a bit of overkill). The allow statement includes all the codecs supported by SipToSis, you can omit any you don't want. The dtmfmode matches the default in the siptosis.cfg file, so if you change it in one place be sure to change it in the other. 75793 is the substitution I made for "mothership" in SkypeToSipAuth.props.

I also added deny and permit lines for extra security. They work for me, but if you have problems try removing them.

For now I still can't see any benefit to using a route for outgoing calls (the only advantage to having a route would be if you are using the SkypeOut service, or if you use softphones that can actually send names as well as numbers, but as I said previously, if I have to use a softphone why not just use a Skype client) but you can send your custom extensions out through your trunk if you like - it may make a difference in the way calls are recorded on the CDR or something (I don't thinks so, but who knows). To do that, when you create a custom extension, instead of using the format

sip/skypeusername@127.0.0.1:5070

instead do

sip/Skype/skypeusername (note this assumes you named the trunk "Skype"!)

One nice thing is when you do a "sip show channels" you can see some REALLY low ping times
Skype/Skype_Caller 127.0.0.1 A 5070 OK (2 ms)

The above is just a first (well, actually now a second) attempt at this so if it helps anyone, great, if not, sorry about that and if it breaks anything, you get to keep all the pieces. The biggest advantage I can see is getting meaningful Caller ID from Skype callers, and also it's good for those who just hate allowing Anonymous Incoming SIP calls - with a real trunk in place these calls should no longer be considered anonymous.

One small caveat about the above: After you've added the from_url= line to siptosis.cfg, you need to be careful that you don't stop and immediately restart SipToSis. For some reason, it starts a java process that doesn't always immediately die when you stop SipToSys. If you then restart everything too quickly, you can get multiple java processes running, each of which is trying to lay claim to 127.0.0.1:5060, and the duplicates start sending their complaints into the /siptosis/log/SipToSis.log file, and if you don't realize it and walk away, you can easily get a full disk in no time flat. I had started and stopped everything a few times in succession while debugging (actually I had been using Webmin to restart the vncserver) and suddenly realized the log file was growing at a ridiculous rate, and found there were about half a dozen instances of java running. By stopping the vncserver and letting it rest for a minute or so, all the java processes eventually went away and then I could restart it and the log was fine. I then restarted the vncserver (which also restarts SipToSis and Skype) and then the log was fine after that. It probably won't be an issue in normal use, but if you are debugging it's something to be aware of. Just another little fun incident to cause me to pull out what little hair I have remaining!

My apologies to anyone who tried to do this on the same day I posted it... if you are smart, whenever I post something you'll wait a day or two before using it, because I don't think I've ever yet made a post of this type and the NOT found a major bug in the few hours or next day. Some of my posts get edited a whole bunch of times before I'm finally through, unfortunately.

As noted in the earlier post, all this information has now been synthesized onto the page at Enlaces ocultos para usuarios no registrados. Inicie sesión o regístrese Aquí

WISEOLDOWL:

I am a little confused with one setting here. Why is fromuser= and username= different value? What does each of them mean to the siptosis gateway? I presume that we only needed the username= to match the one you setup in /siptosis/SkypeToSipAuth.props, which is 75973 in your case.

wiseoldowl wrote:


PEER details:

disallow=all
allow=ulaw&alaw&ilbc&speex
canreinvite=no
context=from-trunk
dtmfmode=rfc2833
fromuser=75973
host=127.0.0.1
incominglimit=1
nat=never
port=5070
qualify=yes
secret=somegoodpassword
type=peer
username=Skype_Caller
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.255

bbhenry wrote:
WISEOLDOWL:

I am a little confused with one setting here. Why is fromuser= and username= different value? What does each of them mean to the siptosis gateway? I presume that we only needed the username= to match the one you setup in /siptosis/SkypeToSipAuth.props, which is 75973 in your case.

wiseoldowl wrote:


PEER details:

disallow=all
allow=ulaw&alaw&ilbc&speex
canreinvite=no
context=from-trunk
dtmfmode=rfc2833
fromuser=75973 <===== Removed this one
host=127.0.0.1
incominglimit=1
nat=never
port=5070
qualify=yes
secret=somegoodpassword
type=peer
username=Skype_Caller
deny=0.0.0.0/0.0.0.0
permit=127.0.0.1/255.255.255.255


Good question - creating trunk settings is something of a black art, and generally I just try things until I get something that works. Did you try it without the fromuser= setting and it worked anyway? I think my reasoning was that the username is used for authentication, but I suspected (probably incorrectly) that the fromuser= just might specify the incoming DID. Bear in mind that even this is still a bit of a hack; it's not precisely the way a trunk should be configured, and that's because every time I thought I was doing it right (by using all the Asterisk trunk options given in SipToSis.cfg) something wouldn't work - at one point I thought it was all working great, then discovered I had no audio on some calls, and that made no sense at all, but when I went back to a more minimalist configuration in the the SipToSis config file and used these settings in the trunk, everything worked, so I was kind of at the point where I was saying, "It works, don't touch it, don't even breathe on it, just leave it as it is!"

But since you asked, I removed the fromuser= line and it still seems to work, so I'll remove it from my original post. Thanks.