Vodia PBX

You need to write it as WAV, 8 kHz mono, 16 bit/sample which is 128 kbit/s. The PBX does not decode MP3 on the fly (also not AAC, WMA or other advanced formats).

This is not crazy. AFAIK there is no special document that covers such a setup. We do the same thing. In our setup, we have an extension in HQ for each branch office (whatever that exactly is ). Then in the branch office we just register to this extension. That's essentially it. It has some drawbacks with the Caller-ID presentation, but this solves many problems with NAT & Co.

Even a gigabit line can be consumed by http or email traffic bursts... It is less probable then on a 33.6 kBit dial up, but still possible.

By default, the local party is between two dashes, looking like "-xxx-". Maybe you can search for that pattern.

For gmail I am using this and it works (except for the account name obviously):

Such a feature exists (as far as I remember) if you are using the multicast PnP method. But I agree, it is surprising that you get devices with a firmware which is at least two years old.

Well that comes from the PSTN gateway audio subsystem..... The alternative is to turn this off and use the trunk hangup detection instead.

I cannot think of one...

Ehh that is a pretty old file...

That is not my impression... Slower releases can also be seen as a sign of better stability. And if a forum had many answered threads which are in the search engines people don't have to raise questions twice. Version 4 is not just about increasing the version number. Seems like other vendors believe that versioning is a marketing instrument...

If you are using Windows you can use the microphone in connection and select it from the MoH menu.

I would say 90 % of the cases packet drops caused by a connection that does not have QoS.

Hmm. Where do you want to see the CMC? On the phone? That will be close to impossible (right now; never say never!). Or in the CDR?

So you want to keep the DID (DDI?) from the incoming call? There is a setting in the domain that instructs the PBX to leave the names unchanged. That might help.

Try locking all calls down (in the admin/ports section). This is the default for new installations anyway. That will not make any difference. The PBX does not respect the codec preference of the UA.

That should work. Check the file provisioned by the pbx in the "generated" directory and look at the dial plan there. There should be a dial plan that takes the 11-digit number. If the PBX provisions something else then check if you selected the right dial plan in the domain PnP settings.

If you turn the logging of other SIP packets on then you should see what the eyebeam returns. That might give us a hint on what is going on.

Yea, in version 4 this fiendly scanner will do this 10 times then the PBX will block the traffic. Of course, one problem remains. The packets take a lot of bandwidth and if your link is "slow" then other valid requests might be dropped. Maybe you should contact roxfarma.com.pe for a statement as the IP address resolves like this: Hostname:www.roxfarma.com.pe ISP:Telmex Peru S.A. Organization:Telmex Peru S.A.

Well, they don't have to. They can just start dialling with the "1" thats all. Or tell them they should raise their hands if they ever used a cell phone!

Try to lock the codec down. Maybe the provider is not able to deal with asymetric codecs.

Well how does the phone know you don't want to make an internal call? That's why the number has to start with a "1" so that the phone knows this will be a 10-digit number. On old PBX systems, you had to use "9" to "seize the line". That is not neccessary in a digital world any more. Instead of using "9" and then potentially a "1" you can now use just the "1" to start dialling a 10-digit number.

It is a little bit tricky. If we provision those images, then all phones will get them (is there any way to tell what phone model it is?!). We don't have any model differentiation for Polycom; all phones are treated the same. If we provision large images then the lower-end models might run out of memory...

I don't believe that will work. At least the pnp.xml file does not contain anything for the 480i CT.

Right. In addition if you are using DNS for TFTP and SNMP, they would also have to support DNS SRV (which they don't).

What? That would be completely off the RFCs. The original Caller-ID is always in the From header. This is because the From-header never changes in the SIP proxy model. If they are using P-Asserted then that one contains the one who is paying the bill. This is almost intrinsic ("It is me, I am paying"). Maybe they support ICID (RFC 3455). This would be a very easy way of knowing who is calling.