cwernstedt

We've had a problem with 3.4.0.3201 (running under Mac OS X Leopard) such that a phone may suddenly not be able to register. In the log the following lines are repeated as the phone tries to register. [8] 2009/11/16 14:56:35: Timeout on UDP transport layer (1512382) [5] 2009/11/16 14:56:35: Final transport error on 1512382: REGISTER The pbx's operation in other aspects seem to be OK. Re-starting the machine on which pbxnsip is running resolves the problem. This has happened about two times over a period of three months, so it's not frequent, but causes a good deal of disruption.

I'm doing it with Vegastream ISDN devices. It works well, however I needed to bypass pbxnsip for incoming fax calls. I route those straight to NET SatisFAXtion through dial plans in Vegastream. The system is very scalable, reliable, and you can send and receive faxes as email attachments. I've got T38 transmissions to work over rather flaky Internet connections too with Net SatisFAXtion as an endpoint. (Though here, reliability is not 100% especially if the calls come from ISDN - a clocking issue, I believe.) /CW

Hi, On a client's system, I have noticed that calls that are forked and picked up at a user's mobile phone are listed in the system's call log, but do not show up in the user's web portal call log. Call trace emails do not seem to get sent either (but I haven't tested this as thoroughly.) Is there a way around this problem? My customer is running 2.1.14.2498, and cannot upgrade to 3.X at this time due to very heavy use. Regards, Christian W

OK. This must be the situation here. Thanks! /CW

Hi, I can't find the web settings for the WAN port on a white CS410 w. 3.0.0.2998 . Under System/IP Setup I can only see "LAN Port". Is there a solution to this problem? /Chris W

I'd also like to chip in that CID as a way to identify a cell phone is not a 100% reliable method. When I travel outside the USA with my phone, CID from my cell phone may not come through at all, or may be represented in a way that the pbx misinterprets. Having the user enter an extension# + pin, is the only truly reliable way to authenticate. This method also makes it possible to allow a user to call into the system and be authenticated from say a client's phone or a pay phone . /CW

Hi, A client has two pbxnsip systems running, and I have set up a trunk on each pbx to route calls to the other, along with dial plan entries such that when dialing an extension which resides on the other system, the call is routed through the corresponding trunk. A problem I have is that when an extension on one system is called from the other, the domain name from the originating system is present in the SIP URL that the receiving system (and it's registered phones) sees. When a user then wants to call back to that number from their phone, the phone will in vain try to contact the originating pbx's domain, and the call cannot be placed. I know this could be solved by setting the "outbound proxy" parameter in the phones, but there are 50+ phones with no simple provisioning, so I'd like to solve this on the pbxes instead. I would like to replace the domain part in the SIP urls for incoming calls on each respective "intra-pbx" trunk with the domain of the receiving PBX. (E.g user1@domainX will look like user1@domainY ) Is this possible? (Or is there some other way to solve my problem without specifying outbound proxy on all the phones.9 Regards, Christian W

Works much better!

Hi, I'm trying to set up two way intercom with Snom phones, but can't find much information about the intercom feature here or on the wiki. (There's a lot of info on paging, but that's not what I'm looking for.) The first problem I'm running into is that when dialing the assigned *-code (*90 in this case), I just get a voice saying "This feature is not available at this time". Any advice would be appreciated! Regards, Christian W

Thanks! The cause of the problem turned out to be that the email-info had been entered in the global email settings, and not in the domain's settings. /Christian

Hi, I'm trying to make the box send email messages, but whatever i enter in the email configuration fields in the logging section, I get the error message below when the box tries to send an email. "No valid source address for sending email to user" I don't have this problem in the non-embedded version of the software. What is the address format that will work on the box? Regards, Christian

I'm using update-2084.tgz for these tests, so the polarity change may either not be included in this build, or it doesn't work in Sweden. (It's as if it works at times, but sometimes not, so it's random.) Regarding the volume and AGC, I think things would work better here if it would be possible to lower the volume just one notch, but the problem with the line staying up when it shouldn't is what concerns me most at this point.

I'm almost sure that Sweden uses polarity reversal, so if you can put that in as an option, the CS410 will propably work in Sweden. (And most likely in the Norway, Denmark, Finland as well.) I also noticed some overheard noise when speaking loud into the handset, which indicates that an option to lower input/output gain might be handy.

In Sweden, it doesn't seem to properly handle tearing down the line when it should. (E.g. when the remote party has put his phone on hook.) Perhaps you need to allow for different countries' disconnect tones. /CW

What would be a compatible one or two port external analog FXO box to use until the built in FXO gateway can be used in Europe? I'm currently trying a Sipura SPA 3000, but it doesn't seem compatible with pbxnsip for placing outgoing calls. /Christian

How do I download to the box with the http-protocol? To which directory should the file go? How do I start it? (No, I'm not particularly familiar with linux.) Is it safe to FTP transfer the /etc/pbxnsip file to a desktop computer for editing, and then transfer it back (replacing the original)? Do I need to check and/or reset permissions? I want to make sure that I don't break anything because this unit is in production, and I'm at an ocean's distance. Christian

How do I install and configure the ntpclient? Are there instructions somewhere? Christian

Hi, I have installed a CS 410 for a client. A problem is that the unit does't indicate the proper time and date in logs. I have tried using the date command over an SSH session, but that setting doesn't take into account that summer time changes, and time is not retained over restarts. How do I set the time and date and how do I make the CS 410 retain proper settings over restarts, and how will the appliance account for summer time and winter time? (Is this documented somewhere?) /Christian

Why not let the calling card function and its authentication process work properly as a means of access to the system? I know I'm repeating myself, but I am really very curious about why my suggestions in this area are not addressed. The present limitations of the calling card (e.g. not being able to call mailboxes) seems more like bugs, rather than reflecting conscious design decisions about how to support (or rather, as it stands, make life complicated for) mobile users. /Christian

OK. I'm not sure that I understand the part about mailbox readout. Can you clarify? Is what you are saying that anonymous cell phone numbers, or callers with messed up or suppressed CIDs, or callers borrowing a friends/client's phone can't be supported to access mailbox readouts when outside the office? My biggest customer (a multinational company) has no standard way of routing calls or identifying mobile callers such that CID without prefixes could be used to route calls according to the client's policy and needs. Further, I think that the PBX's dependece on CID to support for mobile caller's access to the system is a big flaw. Setting aside the lack of flexibility this model creates, there is also the issue of the unreliability of CID (e.g. My cell phone's CID often becomes suppressed when I travel outside the US). Why not fix the calling card function? Basically what's needed there is for the calling card to let the mobile user do eveything permitted from a fixed IP phone (given that user's or the calling card's dial plan) after proper authentication (e.g with a user code+pin). I know I'm whining about this, but this is a major issue that I need to solve to make my customers happy.) Look here for a list of the hurdles for mobile users. /Christian

This seems to have happened with 2.0.3: When callers get transfered to a user's mailbox they will hear an announcment saying that they have the option to either be called back when the extension becomes available, or to leave a message. When pressing #2 to leave a message, they will hear the recorded greeting if such is available. This new behaviour of the PBX is very annoying for the following reasons: 1) The call back option will not work with complex routing setups (e.g. if a special prefix is needed to route an external call), and it is not always desired that a caller gets this option anyway. 2) Being told that when pressing #2 one will be able to leave a message, but instead hearing the user's greeting, is illogical. Is it possible to turn off these new "features". They create confusion for users, and are not helpful. When the mailbox kicks in, the greeting (personalized or anonymous) should be played without any other options at that point. /Christian PS. The calling card system is still a mess.

I have not seen this problem with a Snom 360 w. current firmware, but had several problems off all sorts with earlier versions of Snom 360 firmware. Do you run the latest version of Snom firmware?

OK, well, I don't have any direct destinations entered. The AA is freshly created with no special configuration except for the setting that specifies that the user must press "#" before the search can start. /CW

Hi, I'm not sure what you mean by direct dial options. Where do I find them, and can you give an example of how an overlap could happen? (Searching the Wiki for "direct dial" leads only to a description of the mailbox direct dial prefix.) /CW

I have noticed several calling card related problems that are very annoying, and that I'd like to report: Calling directly to mailboxes via a calling card simply doesn't work. (It doesn't matter what the dial plan looks like.) When an extension has "Call Forward All" to external number, it will not work properly when called from a calling card in the following ways: If the called extension has UAs registered they will ring, which is wrong -- the call should be forwarded. If the called extension doesn't have UAs registered, there will just be silence with no notification to the user about what's happening. (Double wrong!) (In the latter case, the PBX log shows "Could not start call to extension 1141 because there is no registration or the extension is busy" .) Calling card doesn't work correctly with extensions that have a cell phone number attached. The cell phone will not ring. If calling an extension from a calling card, the caller will never wind up in the mailbox regardless of the called extension's mailbox time out settings. Now, one might recommend using the new cell phone features in the auto attendant instead of calling in using a calling card. However this is not a satisfying solution for the following reasons: If a prefix is necessary in the cell phone number as entered in the user's settings, CID matching will not work. (E.g. the the number entered is the settings is 550019174110101 in order to route the call correctly, but the cell phone presents itself as 0019174110101 when dialing in, resulting in a non-match.) CID info is not always tansmitted correctly anyway. Its reliability depends a lot on which operator the phone is attached to. (For example, when I dial numbers in Europe from my U.S phones, the CID may often be suppressed.) A mobile user may need to dial in from a different phone than the cell phone having the number that has been entered. (e.g the battery may be dead.) Calling card functionality in cellphones (e.g some Ericsson phones) usually don't have provisions for navigating complex menus. Typically it is possible to send access code + the desired number + #, and that's it. The need to navigate menus should be kept at a minimum since mobile users may be walking or driving a car while operating the phone. With the above described problems, I would say that support for mobile users in pbxnsip is currently lacking in several essential areas. Regards, Christian W