Jump to content

jlumby

Members
  • Posts

    290
  • Joined

  • Last visited

Posts posted by jlumby

  1. I have the same quality issues when registering multiple PBXnSIPs to one. Even when on the same LAN. I think it may have something to do with the load from how frequently they need to re-register to stop the registration from expiring. I don't understand why I can set a cisco phone for 1 hour and it actually uses it's registration time. However if I set the PBXnSIP trunk to one hour, it refreshes every 15 seconds, and if you try to force it to 1 hour, the registration expires.

  2. I had originaly tried registering them to eachother, and had found that it lead to nothing but problems.

     

    When sending an ANI that is different than the authentication username, everything was originally OK, until I restarted the servers, and then all outbound calling failed until I changed the ani to match the auth username

     

    For some reason setting the refresh time to anything more than 45 seconds causes the registration to expire. (you would not think there would be any compatibility issues between 2 systems of the same manufacturer that are on the same subnet)

     

    If you have multiple trunks, and the machineg that they are registered to reboots, then it causes the service on the remote PBX to fail, and become unresponsive

     

    If you have multiple trunks refreshing every 45 seconds, it causes load on the main server that creates poor call quality, and large delays even though the processor is sitting at a very low utilization

  3. Here is what my log file is showing

     

    [2] 2009/03/06 10:06:21: SOAP: Request from untrusted IP address

    [5] 2009/03/06 10:06:21: Receive SOAP request via HTTP interface

    <?xml version="1.0" standalone="yes"?><env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:sns="http://www.pbxnsip.com/soap/pbx"><env:Body><sns:MakeCall><domain>qwesthost.twincitytelephone.com</domain><callingDevice>211@officevoip</callingDevice><calledDirectoryNumber>205</calledDirectoryNumber></sns:MakeCall></env:Body></env:Envelope>

    [5] 2009/03/06 10:06:21: INVITE Response 400 Bad Request: Terminate 8525d10c@pbx

  4. I have been running into issues with the PBXnSIP service on a Win 2000 server machine. I am not sure if it is due to version 3.3.0.3147 or if it was the latest round of Microsoft updates (they happened about the same time). The Server did a automatic update/reboot at 3AM and the next morning I came in to find the service was not automatically running. I Clicked start, and it came right up. Since then I have been testing to see if it will come back up automatically on a reboot, and it still will not. I then tried version 3.3.0.3152 and I could not get it to start at all after multiple tries. I then went back to 3.3.0.3147 and after a handfull of tries, it eventually started. I am not exactly sure how to troubleshoot it. Here is what the windows event log is saying.

     

     

    Application popup: pbxctrl.exe - Entry Point Not Found : The procedure entry point GetAdaptersAddresses could not be located in the dynamic link library iphlpapi.dll.

     

    Timeout (30000 milliseconds) waiting for the pbxnsip PBX1 service to connect.

     

    The pbxnsip PBX service failed to start due to the following error:

    The service did not respond to the start or control request in a timely fashion.

  5. Is there any way that you could setup PBXnSIP so that it will allow calling between 2 trunks. I am Interested in allowing one branch office to connect through it's sip gateway trunk to the main office's PBXnSIP, and then out the main office's Sip Registration trunk to the ITSP. This would be possible if you could assign a dialplan to the Sip gateway trunk that links the PBXnSIPs together. I know it is possible by using a sip registration from the remote office to the main office as an extension. However PBXnSIP is very problematic when doing this, especially when it comes to sending callerID, and the short registration time that is necessary, leads to excessive load, and poor call quality on the main office's server.

  6. I just installed Version 3, and I noticed that if someone takes a call through a hunt group it does not show their extension as busy, and the features to call or intercom do not seem to work. I am running in MultiDomain mode, and running pbxnsip version 3.3.0.3147 (Win32)

     

    I just noticed that all of my attempted calls from the PAC are still sitting idle on the system.

     

    2009/02/24 08:36:54 202@officevoip@officevoip 211@officevoip idle

    2009/02/24 08:37:02 203@officevoip@officevoip 211@officevoip idle

    2009/02/24 08:37:12 211@officevoip@officevoip 211@officevoip idle

    2009/02/24 08:37:35 *90201@officevoip@officevoip 211@officevoip idle

    2009/02/24 08:40:34 208@officevoip@officevoip 211@officevoip idle

    2009/02/24 08:41:19 202@officevoip@officevoip 211@officevoip idle

    2009/02/24 08:41:26 211@officevoip@officevoip 211@officevoip idle

    2009/02/24 09:40:13 206@officevoip@officevoip 211@officevoip idle

    2009/02/24 09:40:25 *90206@officevoip@officevoip 211@officevoip idle

  7. I have a situation where I have 2 PBXnSIP servers registering their trunks to a third PBXnSIP server as different extensions. The problem I am having is even though the accounts are different, one server unregisters the other one. The registrations bounce back and forth based on the last one to register. The servers are directly connected to eachother on the same subnet, so there cannot be any nat issues. Below are the emails I constantly get:

     

     

    Source address for "12182604488" <sip:12182604488@10.0.0.4>;tag=17066

    has changed from udp:10.0.0.2:5060 to udp:10.0.0.3:5060

     

    REGISTER sip:10.0.0.4 SIP/2.0

    Via: SIP/2.0/UDP

    10.0.0.3:5060;branch=z9hG4bK-30ebe24cc32d1422b18c9521081dba63;rport

    From: "12182604488" <sip:12182604488@10.0.0.4>;tag=17066

    To: "12182604488" <sip:12182604488@10.0.0.4>

    Call-ID: d2zvps87@pbx

    CSeq: 9598 REGISTER

    Max-Forwards: 70

    Contact:

    <sip:12182604488@10.0.0.3:5060;transport=udp;line=d3d94468>;+sip.instance="<urn:uuid:39b32d12-074d-4dc8-a443-66bb428b26a6>"

    User-Agent: pbxnsip-PBX/3.2.0.3144

    Expires: 3600

    Content-Length: 0

     

    Source address for "19522531500" <sip:19522531500@10.0.0.4>;tag=17066

    has changed from udp:10.0.0.3:5060 to udp:10.0.0.2:5060

     

    REGISTER sip:10.0.0.4 SIP/2.0

    Via: SIP/2.0/UDP

    10.0.0.2:5060;branch=z9hG4bK-369244384ef1e7d8c8b824385ac8c662;rport

    From: "19522531500" <sip:19522531500@10.0.0.4>;tag=17066

    To: "19522531500" <sip:19522531500@10.0.0.4>

    Call-ID: d2zvps87@pbx

    CSeq: 14494 REGISTER

    Max-Forwards: 70

    Contact:

    <sip:19522531500@10.0.0.2:5060;transport=udp;line=45c48cce>;+sip.instance="<urn:uuid:00294823-18be-4784-8ae1-3d6c2cd672ae>"

    User-Agent: pbxnsip-PBX/3.2.0.3144

    Expires: 3600

    Content-Length: 0

     

    Source address for "12182604488" <sip:12182604488@10.0.0.4>;tag=17066

    has changed from udp:10.0.0.2:5060 to udp:10.0.0.3:5060

     

    REGISTER sip:10.0.0.4 SIP/2.0

    Via: SIP/2.0/UDP

    10.0.0.3:5060;branch=z9hG4bK-0563a06f02bfcd037dc9916022766536;rport

    From: "12182604488" <sip:12182604488@10.0.0.4>;tag=17066

    To: "12182604488" <sip:12182604488@10.0.0.4>

    Call-ID: d2zvps87@pbx

    CSeq: 9596 REGISTER

    Max-Forwards: 70

    Contact:

    <sip:12182604488@10.0.0.3:5060;transport=udp;line=d3d94468>;+sip.instance="<urn:uuid:39b32d12-074d-4dc8-a443-66bb428b26a6>"

    User-Agent: pbxnsip-PBX/3.2.0.3144

    Expires: 3600

    Content-Length: 0

     

    Source address for "19522531500" <sip:19522531500@10.0.0.4>;tag=17066

    has changed from udp:10.0.0.3:5060 to udp:10.0.0.2:5060

     

    REGISTER sip:10.0.0.4 SIP/2.0

    Via: SIP/2.0/UDP

    10.0.0.2:5060;branch=z9hG4bK-af2c5abca0e1ecd5a0813da65f04532b;rport

    From: "19522531500" <sip:19522531500@10.0.0.4>;tag=17066

    To: "19522531500" <sip:19522531500@10.0.0.4>

    Call-ID: d2zvps87@pbx

    CSeq: 14489 REGISTER

    Max-Forwards: 70

    Contact:

    <sip:19522531500@10.0.0.2:5060;transport=udp;line=45c48cce>;+sip.instance="<urn:uuid:00294823-18be-4784-8ae1-3d6c2cd672ae>"

    User-Agent: pbxnsip-PBX/3.2.0.3144

    Expires: 3600

    Content-Length: 0

     

    The trunk 12182604488 is only on 10.0.0.3 and registers to 10.0.0.4

     

     

    The trunk 19522531500 is only on 10.0.0.2 and registers to 10.0.0.4

     

    I noticed that the SIP Tag on both is the same, could 10.0.0.4 be confused by getting the same Tag from 2 different servers? Not really sure what the Tag value is/means.

  8. I am having some issues getting this to work properly. After some investigation, I found out that when I send an ANI that does not match the account number (username), the PBXnSIP server that the trunk is registered with returns a 401 error, however if I set the ANI to match the account number, then the outbound call works properly. The initial registration, and receiving calls is never an issue.

  9. I have experience with the Cisco 7912 and according to Cisco's documentation, the 7911 is actually newer, and uses a config file that is similar to a 7941 (which I have a lot of experience with). If I had a phone, I could bind it to my callmanager, and probably generate a config file, edit it to make it compatible with PBXnSIP, and send it back to you.

  10. I am looking for a way to not hardcode the ANI for each extension, however use some type of variable in the ANI field so that it can pull, and use the ANI from the invite message. I have situations when running the hosting version, and I have 1 PBXnSIP server registered to another as a trunk, and right now the only way to send caller ID on a per station basis of the remote system is to create a trunk and dialplan per each outbound caller ID, The problem is this method is slow, and an administrative nightmare.

  11. Hold transfer and blind transfer are not a problem, they show up automatically during the call (you might need to press the more button) unless the config file is set to suppress the softkeys (or maybe if you have real old firmware). 8.10 is the current firmware. As for monitoring another extension with a BLF, Cisco's callmanager cannot even do it (you need a 7961 phone). They have not supported the 7914 aom with sip on their callmanager platform until callmanager 7 was released. I have not had a chance to try it, I am still running call manager 6.0.1 I am hoping to upgrade my callmanager to 7 soon so I can figure out if I can make it work with PBXnSIP as well

  12. I have found that this issue runs deeper than I had expected. Today when I was doing a training session for one of our new hosting customers, I had them all in front of 3 different computers, and I had them all log into their individual web portals at the same time with different (extensions) usernames and passwords, however when the login screen processed, they were all logged in as the same person. I am still running 3.1.2.3120

  13. I had an experience this morning where I was working on some extensions in a specific domain, and another tech logged in remotely to work on a different domain. After getting some customer complaints, I found that the accounts I was working on ended up in the domain that the other tech had logged into. Is there a way to force the second person to log in as read only, or at least be aware that someone is already in making programming changes? I am currently running 3.1.2.3120 win32

×
×
  • Create New...