Jan Forcier
-
Posts
11 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by Jan Forcier
-
-
Can you tell us what timezones that are? Ideally in the PBX timezone format... (see http://wiki.pbxnsip.com/index.php/Localization#Time_Zones). Then we will include it in the next build. It is clear that we don't have all time zones, but don't forget that we want to support multiple zones at the same time and we want to be able to automatically provision them!
We require all Canadian time zones, described here:
http://www.timetemperature.com/tzca/canada_time_zone.shtml
In addtion, we have a number of customer in the middle east so have interest in the following zones
http://www.worldtimezone.com/map-time-middle-east24.php
Also, a number of people are using our service on the pacific rim:
http://www.worldtimezone.com/time-asia24.php
As you can see, it would be much easier if all TZ's are supported with a simple UTC offset value which can be set to any valid numeric zone.
JF
-
I am using outbound proxy and not STUN at the same time on the device. I'm also not using it on a server trunk since the server is on the open internet, no firewall
As I mentioned in the original post, I am using outbound proxy (on the device) exactly as described.
The NAT is a Linksys NAT with fully updated firmware.
However, I've noted that other ATA's (Linksys) also seem to have be getting blocked by NAT which does not happen on earlier builds.
Still does not work. Are you sure that this build does not have "outbound proxy" support broken?
JF
FYI:
I've been using PBXnSIP for more than a year and I doubt I'm making a trivial error.
I provisioned the factory default blank Snom 300 UA using PBXnSIP (this was really what I was testing) so if any settings are wrong, then there is a problem with the provisioning.
Essentially my procdure was:
1) Take new Snom 300 from box, upgrade to newest firmware
2) Provision using PBXnSIP
3) Add, OP to account. The UA put in "sip:66.119.176.21:5061;transport=tcp" after I saved. (this is the IP of my server, not sure why it wanted to use 5061 but I don't see why this would be a problem
4) Test, find I'm getting one way audio
- I then tried some troubleshooting but can't find a problem so I posted to your forum.
JF
The trunk may use STUN to allocate a public IP address. This is very unreliable, therefore we strongly recommend not to use this feature. However, there are stupid marketing people who believe that if that feature does not show up in the datasheet the product is inferior. We all know that this is bulls*** and STUN is just creating huge support problems.When an extension registers, it should just point the outbound proxy towards the PBX. On the snom phones, you can use even use TCP (or TLS) transport layer. Just use an outbound proxy like "sip:2.3.4.5:5060;transport=tcp". Then the NAT problems should also disappear, because even crappy routers support TCP connections. Of course, do not use STUN on the phones as well.
-
No, my understanding is that PBXnSIP does not *have* STUN so I don't have a STUN server to use.
I'm using outbound proxy but this does not appear to work
JF
I guess you are not using STUN on the phones?So far it seems that other installations do not have such a problem.
You can do PCAP traces both from the phone and from the PBX - then it should be easy to see where the RTP gets lost.
-
I guess you are not using STUN on the phones?
So far it seems that other installations do not have such a problem.
You can do PCAP traces both from the phone and from the PBX - then it should be easy to see where the RTP gets lost.
-
I'm getting the classic "one way audio" (NAT blocking one call leg) with Snom 300, firmware 6.5.8 on 2.0.3.1708 (Unix)
I used PBXnSIP to provision the phone and confirmed that the outbound proxy is/was set to the server correctly.
The Snom 300 registers, but one audio leg (inbound to the phone) gets blocked behind a NAT.
Is this a problem with the build or with Snom 300
-
BUG: TZ support
It's very useful that time zones are now supported, however, there are only a limited number included.
We often have customers in time zones other than the ones listed.
I would suggest this should follow the standard which is UTC (GMT) +/- some offset and support any valid zone.
Note that in Canada, (and other contries) there are 30 minute offset time zones (UTC -2.5 TZ)
-
I am setting up redundancy, however, there are 2 things that are unclear to me (and not documented)
1) There is the following note in the wiki:
"On all error codes. In this case, all error codes will trigger the failover process. Note that also call redirect will be treated as a error code, as the redirection destination can easily be abused to route calls though expensive routes."
--> What does this mean "in practice"? Does this mean that it will be impossible to forward and/or transfer a call?
2) What is the undocumented "Request Timeout:". I'm guessing this is how long the server will try the trunk before unconditionally giving up.
Jan Forcier
-
Changes were made to CDR logging without any documentation the CDR fields are now:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sns="http://www.pbxnsip.com/soap/pbx"><env:Body><sns:CDR><CallID>9bed954b-553c6ab1@66.119.176.19#918ce0069c</CallID>
<Type></Type>
<Domain></Domain>
<From></From>
<To></To>
<FromUser></FromUser>
<ToTrunk></FromTrunk>
<TimeStart></TimeStart>
<TimeConnected></TimeConnected>
<TimeEnd></TimeEnd>
<StatisticsForward></StatisticsForward>
<StatisticsReverse></StatisticsReverse>
</sns:CDR></env:Body></env:Envelope>
They were:
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sns="http://www.pbxnsip.com/soap/pbx"><env:Body><sns:CDR><CallID>7e9f77c-5b69daf3@74.113.25.228#108696767</CallID>
<Charge></Charge>
<From></From>
<To></To>
<Duration></Duration>
<Start></Start>
</sns:CDR></env:Body></env:Envelope>
-
We have put version 2.0.1 on the download page (http://www.pbxnsip.com/downloads.php). The release notes can be found at http://wiki.pbxnsip.com/index.php/Release_Notes_2.0.1.
Upgrades: We believe that the 2.0.1 fixes several important issues that we found in the 2.0.0 release. If you don't experience problems with the 2.0.0 release, there is no need update. However, if there should be open issues with the 2.0.0 installation, we recommend to move to 2.0.1. We recommend to backup the working directory and the pbxctrl.exe executable before performing the upgrade.
It appears that 2.0 keys do not work on 2.0.1 on Debian 3.1
Is this a known issue or do we need a new key generated?
-
We have put version 2.0.1 on the download page (http://www.pbxnsip.com/downloads.php). The release notes can be found at http://wiki.pbxnsip.com/index.php/Release_Notes_2.0.1.
Upgrades: We believe that the 2.0.1 fixes several important issues that we found in the 2.0.0 release. If you don't experience problems with the 2.0.0 release, there is no need update. However, if there should be open issues with the 2.0.0 installation, we recommend to move to 2.0.1. We recommend to backup the working directory and the pbxctrl.exe executable before performing the upgrade.
This fails on a generic barebones debian system due to a required undocumented shared library.
./start
/var/pbx/pbxctrl: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
Can we get a version that does not require shared libraries?
SPA2102 T.38 Fax settings
in Linksys Phones
Posted
I'm testing T.38 Fax with an SPA 2102, with Snon 2.03 latest build, Linux.
Our carrier (for inbound) supports T.38.
I've followed the instructions I can find for the SPA2102 but when I attempt T.38 the faxing fails (g711u works but with the usual reliability problems)
The T.38 Pass thourgh appears to be working since the INVITE packets in the PBXnSIP log clearly show this is passed to the UA (see below).
Do you know the settings which will work with SPA2102 T.38? If you know another ATA that has been verified to work, I'd like to know the settings for this adapter and I can possibly buy one.
INVITE packet below--------------------------------------------
INVITE sip:6044844702@159.18.161.101:5060 SIP/2.0
Via: SIP/2.0/UDP 66.119.176.21:5060;branch=z9hG4bK-ad99b3cf8bcd8ade9e941caa73a31e86;rport
Route: <sip:6046379679@159.18.161.67;ftag=159.18.161.101+1+400593+54d16769;lr=on>
From: <sip:6046379679@sproxy.netfone.ca>;tag=c4a452d288
To: Metrobridge <sip:6044844702@159.18.161.101:5060>;isup-oli=00;tag=159.18.161.101+1+400593+54d16769
Call-ID: FC2ED118@159.18.161.101
CSeq: 6652 INVITE
Max-Forwards: 70
Contact: <sip:6046379679@66.119.176.21:5060;transport=udp>
Supported: 100rel, replaces, norefersub
Allow-Events: refer
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, PRACK, INFO, PUBLISH, NOTIFY, SUBSCRIBE, MESSAGE
Accept: application/sdp
User-Agent: voipportal-PBX/2.0.3.1708
Content-Type: application/sdp
Content-Length: 273
v=0
o=- 428992889 428992891 IN IP4 66.119.176.21
s=-
c=IN IP4 66.119.176.21
t=0 0
m=image 51072 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:200
a=T38FaxUdpEC:t38UDPRedundancy