Jump to content

Jan Forcier

Members
  • Posts

    11
  • Joined

  • Last visited

Everything posted by Jan Forcier

  1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 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)
  7. 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
  8. 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>
  9. 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?
  10. 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?
×
×
  • Create New...