Vodia PBX

(1) Do not use STUN on the phone. Use PnP instead. (2) Do not use a firewall that wants to be smart, but that is not.

As far as I can tell, we had good experience with both of them...

Is there a option to tell the cvlc what the packet size for RTP should be? Try to set it to 10 ms or 20 ms. That might help solving the problem.

As posted in another thread, we did spnd some time on it and there is a problem when the packet length is not 10, 20, 30, 40 (multiple of 10) ms. This is typical in the telecom world... If the packet length is not multiple of 10 ms, the PBX seems to have problems with the internal wrap-around (leaving a noise carpet at the end of the buffer). We made a code change that should make it possible to send any length for MoH, we are investigating it. If you would like to check as well, send a PM and we'll send you a link to a build for verification.

Eh... Das ist hier das Forum für snom ONE, die PBX von snom! Mit Cisco-Produkten kennen wir uns nicht so gut aus. Vielleicht die Gelegenheit, mal snom 190 mir snom ONE zu probieren? Das geht vielleicht einfacher .

There was a problem when the RTP stream for MoH was not using a frame length of 10 ms multiple. That problem should be fixed in the head version, we are currently verifying that the problem was solved; and after that it is time for a "How-to" that explains how to set this up.

It would be intesting to see the INVITE, especially line 28. Then we might know what the problem is, and if it can be fixed by configuration.

There used to be an application called pagmoh that can generate the RTP streams (in Windows) from the mic input and send the RTP stuff to the speaker. Maybe this will help you. If you are using the mic loopback, you can practically use any application that generates speaker output and send it back to the mic input.

Can you start a new topic and include the SIP INVITE message that is being sent to the provider? Check out the logging (http://wiki.snomone.com/index.php?title=Logging_SIP_Settings) for that. What provider is it?

Unfortunately, G.729A is part of the patent war that you see right now in the cell phone world. We have made a license agreement, so no problem there . However, the way G.729 is licensed is by the number of calls. Because we cannot license "unlimited" calls (and we have to pay per call), there are certain limits on how many calls you can have in parallel. And this is also the reason why the free edition cannot have G.729 calls. We thought for a long time to support also other low-rate codecs that are free. However, wich one? iLBC? speex? At the end of the day, we are depending what the service providers offer and it seems that we are pretty much stuck with G.711 and G.729.

Well that you are trying to do is route the call from one trunk to another trunk. So in addition to the trunk to flowroute, you need to have another trunk that goes to Lync. On that trunk, you must tell the PBX what dialplan to use, and the way it works right now is to tell the PBX to "assume the call comes from an extension"; and assign that extension the right dial plan. This would be outbound dialling then. Inbound will also be challenging. you probably have to do the same thing and tell the PBX which extension to assume, so that the call can be dialled in the other direction. I would choose two extensions with two dial plans, so that the outbound dial plan always lands on the trunk to flowroute and the inbound always lands on the inbound always lands on the trunk to Lync. I have never tried this; using the PBX as a IP-IP gateway sounds like an interesting experiment...

Of course you also need to use the username and password in the outbound trunks, otherwise the provider will most likely reject outbound calls, unless he just trust the IP address. As outbound proxy I would copy and paste whatever you have in the inbound trunk.

Well, the only way to get this working is to set the codec preference for the trunks. It is still not so easy, lets just assume for a second that the trunk provider sends 180 Ringing without SDP when you start the call and the phone receives 183 with a SDP. In that case, the PBX has to make a decision. It is legal in SIP to change the codec later, but unfortunately there are a lot of problems on the interoperability side (we tried that a couple of years ago and it was a big problem for support). So thats how you end up in transcoding situations. Re-INVITE would be another option, but again we had a lot of interop-problems here so we kept the call flow as simple as possible (only in the case of a attended transfer we do a Re-INVITE). If you have to transcode from G.711 to G.729, especially on a trunk, the situation could be worse. The quality should be still reasonable good for a G729 call; and if you dont have too many trunk calls, then the CPU load should also be okay. Having something where you have to transcode e.g. from GSM to G729 will have much worse audio quality. Honestly, I would keep it the way it is right now, it would not get much better if you let the phone do the transcoding (from linear to G.729).

Right, but you have to register only the inbound trunk. The outbound trunks are not registering, they are just sending the (outbound) traffic to the same location where the inbound trunk is registering to; using the gateway mode. So that the carrier does not "see" that you actually have multiple trunks.

There is a setting on the phone, I think this is here: http://wiki.snom.com/Settings/cw_dialtone. If you change the template for the snom_3xx_phone.xml, then it should do the magic: <cw_dialtone perm="RW">off</cw_dialtone>

Of course the PBX tries to negotiate a codec that does not require transcoding. But keep in mind, it is not only A and B-party that need to understand the codec, it must also be understood by the PBX (otherwise such features as call recording or barge/listen in would be impossible). The way SDP works, it is not always easy, especially when things like T.38 may also be in the game. I would say as a general rule, either give as much freedom to the PBX to pick the best codec or just have everyone just offer one codec. The latter approach is to avoid negotiations at all; and it works great as long as all parties support that codec.

It is a old settings, so far we dont see a reason why we should remove it. I thought most SIP trunk providers could "already" deal with media in the ringback phase, but it seems that there is still stuff out there which has a problem with that. Sending media during the ringback phase makes it e.g. possible to play MoH in the ACD while waiting and it does reduce the time for the pickup media establishment.

Yea the PIN should be on the keypad on the phone. IMHO it is all a little screwed up, PIN should be only on the keypad, never in the web interface but it seems the phone guys have a different opinion.

There is a settings called "Ringback", change it to "message 180" and givbe it a try.

Well, my point is that you'll have to split hte trunk up. You can keep your inbound trunk as is (just change it to inbound only), and then add two more trunks for outbound. If you are using a registration trunk, those two outbound trunks should be changed to gateway/outbound only with the same outbound proxy like the inbound trunk.

Maybe this is related to the problem with the kernel version (other thread).

So do internal calls between the extension work properly? If yes, we can rule out tricky NAT/routing problems. Otherwise, "in theory" the PSTN setup should work out of the box...

I think this was a problem with the Mozilla or Firefox, but there is a workaround and it will be included in the next build. Also there was a post recently about this in the forum, so that you can change one of the templates and the problem should also be gone.

If you have file system access, you can always sneek into the domains directory and view the XML. There you find the domain admin PIN which you need to go from admin to user mode. Or you can change the template for the phones, and set the admin mode to "off" and after the next reboot the phone will be in admin mode again. It was suppsed to be a feature to keep users from screwing up the phones and then call support (looking as innocent as possible).

Right now we pretty much coded pretty much what is in the templates. There is not more (hidden) stuff... Also, the email subsystem is not the same like the HTML subsystem, it is really just a small subsystem to get the email sent out with the content that we needed. But agreed, at some point we need a documentation for it.