Jump to content

olecoot

Members
  • Posts

    150
  • Joined

  • Last visited

Posts posted by olecoot

  1. Well, if someone pulls the plug on the phone and the other side does not disconnect (or there is no other side), that call will stay up for one more hour... Not good.

     

    Is this one-way video and there is no audio going on? In two way video it should actually not hangup. In one-way audio (and fax) it will hang up; that#s debatable and maybe we need to change this.

     

    This is two-way video/audio; in other words a two-way video call. So if we set this number at <timeout_connected>3600</timeout_connected> this will affect only the video/audio call and not voice only calls? I guess I'm still a little confused as to what this number controls.

     

    One of the tests that we conducted this morning was to establish a normal audio-only call. After about 5-6 minutes on the same call, we switched on the cameras, exactly 120 sec later the call dropped, both audio and video.

  2. There is a setting in pbx.xml labeled "timeout_connected" which by default is 120. We are experimenting with video calls and they are dropping precisely at 120 seconds due to RTP timeout. A regular non-video call works as expected.

     

    What are the values that can be placed in the "timeout_connected" setting and what ramifications are there to changing this value?

     

    PBXnSIP version 4.2.0.3958 CentOS 5

  3. Unfortunately, the support web site is geared toward the snom phone and not conducive to PBXnSIP. The MAC address of an affected phone is necessary to open a ticket. We do not use snom phones at this time.

     

    Also, all of my open tickets are now missing. I realize that PBXnSIP is no longer PBXnSIP but there should be a way to open a support ticket without having to enter an snom phone MAC address.

  4. We have a support contract with PBXnSIP and we can no longer send email to the support email address. Those emails started bouncing yesterday. Where do we send support email now? Also, how do we get to the PBXnSIP support ticket site now??

  5. thanks for the update, but the issue with the polycom BLF remain the same, once of your ext that you watch gets a call the light will just stay on forever.. as well when i am on the phone and one of the ext gets a call i will experience a call waiting beet as i would have a beep,

     

    Is this version available for CentOS 5?

  6. We are testing version pbxctrl-centos5-4.1.0.4031 and have come across two issues dealing with recording.

     

    1. The record all feature appears to be broken in this release. I have tested this using the following settings:

     

    Recording default for this domain: all on

    Account Recording: default

     

    Recording default for this domain: all on

    Account Recording: all on

     

    Recording default for this domain: all off

    Account Recording: all on

     

    In each scenario, there is no recording created.

     

    2. Recording does work if I use the *12 code. However if I have more that one email address defined for the account, the second email address will receive the recording attached as a zero byte file. The first email address in the list is the only one that receives a playable recording.

     

    Are these known issues and are they actively being worked on?

    Is version pbxctrl-centos5-4.1.0.4031 the latest RC? If not, can you provide a link to the newest release please?

     

    Thanks in advance.

  7. Is the "Show Test Area" on the domain dial plan configuration page operational? I think it is supposed to test the dial plans that are configured above. If anything is typed into the "Input" text field the result is always "No pattern found for the dialed number"

     

    How is this to be used?

     

    Thanks

     

    Version 4.1.0.4031 (Linux) CentOS

  8. We tried to reproduce it here without success few times. Could you both send support@pbxnsip.com an email with the dialplan text? (On the dialplan page, you can click on the "Click here to switch to a text-based editing window for the dial plan" to get the dialplan text)

     

     

    Cannot remove in GUI or Text mode.... 4.1.0.4031 (Linux)

     

    Will open a seperate thread but the Test Area does not work either...

  9. Version 3? Nothing changed in V3...

     

    In version 4 it is adjustable. Not sure if from the web interface, but the duration is a setting which can be changed like all other global settings.

     

    Yes sir :) I am aware that it is adjustable in version 4 :)

     

    What I am asking is "Is it adjustable in version 3?"

  10. That setting is still there in V4 (called "max_ring_duration"). I know we changed the login with the trunk timeout and that required some clean up. But V4 should be in a good shape regarding this topic.

     

    So from your response, I can assume "max_ring_duration" is not adjustable in version 3.x??

  11. We offer our customers a hosted PBX solution where we have multiple domains, plus multiple trunks per domain on our servers which are located in a data center. All of our production servers are on one of the 3.x versions of PBXnSIP.

     

    Some of our customers are making calls to toll free numbers where the menus in the IVR system are being played as ringback. This is common with US toll-free numbers, since it allows them to avoid paying for those calls. The issue is that the playback on to the phone is cut off at the 60 second mark and the customer cannot continue to the next IVR or get to a live person.

     

    In PBXnSIP ver 4.x there is a setting labeled "Maximum ring duration" which when set to a value of 60s or more, allows the completion of the playback and the person making the call can continue on.

     

    We have three issues:

     

    1. We haven't sufficiently tested v4.x to the point where we feel confident in deploying it to our production environment.

     

    2. We have been unable to find the comparable variable in v3.x to the "Maximum ring duration" in v4.x

     

    3. Additionally we have tried adjust a comparable setting on the phone itself without success.

     

    Is there a hidden variable or one that is named differently in v3.x that would allow us to adjust the ring duration and correct the problem?

  12. I think you definitevely have to use a newer version that 4.0.1. There were some problems with the loopback trunk that have been fixed meanwhile.

     

    I'm using what is available on the web site. Perhaps those links could be updated?

     

    Can you provide the link for a newer CentOS build?

  13. Hi pbxnsip support,

     

    Any update on this issue?

    I tried 4.0.1.3499 and still the call couldn't go through. And I got following error messages.

    [5] 2010/05/14 14:01:18: Received loopback request without tag

    [2] 2010/05/14 14:01:18: Call Reject: Could identify call domain

     

     

    Has there been a step-by-step write up of the procedure for getting inter-domain dialing to work properly in version 4.x? It would prove to be a lot less frustrating to set up. We've been battling the same issue since the release of 3.x.

     

    We currently host multiple domains with each domain having multiple trunks on a many servers. We really need to get this to work.

  14. I quickly tested this loopback scenario again (using the latest and greatest 4.0.1.3424, let me know if you need a build/OS). The PBX blocks the loop request if the "detect loopback" is on, once it is turned off it is working as it should.

     

     

    So continuing development on 3.x is not happening? We would prefer a fix be included in 3.x development strain. Is this at all possible?

     

    When do you expect 4.x to go GA? For the sake of testing, please provide the link to a CentOS 5 version of 4.x. We will provide critical feedback.

  15. can you post some exact instructions on how to set this up?

    im sure it is much better to keep the traffic within the server rather then terminating with another carrier

     

     

    To PBXnSIP:

     

    To resurrect an old issue .... Has there been an advancement in this scenario? The issue is still not fixed. We have just installed version 3.5 (Linux) and we use a stateless soft switch and cannot dial domain to domain on the same server. Our soft switches do not manipulate packets to or from the PBX. They are true proxies.

     

    Step-by-step detailed instructions would be much appreciated. Again, our situation is a hosted environment, where we have servers with MANY domains and MANY trunks per domain on the same machine. Every build after 3.1 has had the issue. It is becoming very frustrating! We are a large provider using your product. Many of our customers make calls between themselves and we have reached a point where we are beginning to move customer domains to other servers so that our customers can call each other. Obviously this is not a scalable solution.

     

    This has to be addressed in the 3.5 branch.

  16. The best way to deal with this is still to use an external (stateless) proxy or gateway that receives all traffic, no matter if it later will terminate in the PSTN or on the same server. That is a "idiot proof" way of dealing with the problem.

     

    The loopback is a hack that tries to get installations going where something external is not an option. Loopback still has issues with the ANI presentation.

     

    We use that very scenario, a stateless proxy where all calls go. It is when the proxy sends the INVITE back to the originating PBX to a domain on the same PBX the call does not complete.

     

    From PBXnSIP logs when making a domain-to-domain call on same server:

     

    [9] 20091002073424: UDP: Opening socket on 0.0.0.0:53238

    [9] 20091002073424: UDP: Opening socket on 0.0.0.0:53239

    [8] 20091002073424: Could not find a trunk (4 trunks)

    [9] 20091002073424: Resolve 8664: aaaa udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8664: a udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8664: udp 10.1.1.110 5060

    [6] 20091002073424: Sending RTP for 61ffb548-b9af7923-fe7b9e36@10.1.1.110#7170d387ad to 10.1.1.110:2264

    [9] 20091002073424: Resolve 8665: url sip:300@10.1.1.110:5060

    [9] 20091002073424: Resolve 8665: udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8666: url sip:501@10.1.1.204:5060

    [9] 20091002073424: Resolve 8666: udp 10.1.1.204 5060

    [8] 20091002073424: Play audio_moh/noise.wav

    [9] 20091002073424: UDP: Opening socket on 0.0.0.0:51858

    [9] 20091002073424: UDP: Opening socket on 0.0.0.0:51859

    [9] 20091002073424: Resolve 8667: url sip:<PROXY_DOMAIN_NAME>

    [9] 20091002073424: Resolve 8667: naptr <PROXY_DOMAIN_NAME>

    [9] 20091002073424: Resolve 8667: srv udp _sip._udp.<PROXY_DOMAIN_NAME>

    [9] 20091002073424: Resolve 8667: a udp s-cscf-1.<PROXY_DOMAIN_NAME> 5060

    [9] 20091002073424: Resolve 8667: udp <PROXY_IP_ADDRESS> 5060

    [5] 20091002073424: UDP: recvfrom returns EAGAIN

    [6] 20091002073424: Send codec pcmu/8000

    [9] 20091002073424: Resolve 8668: aaaa udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8668: a udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8668: udp 10.1.1.110 5060

    [8] 20091002073424: Answer challenge with username <CALLING_NUMBER>

    [9] 20091002073424: Resolve 8669: udp <PROXY_IP_ADDRESS> 5060 udp:1

    [9] 20091002073424: Resolve 8670: udp <PROXY_IP_ADDRESS> 5060 udp:1

    [9] 20091002073424: Message repetition, packet dropped

    [5] 20091002073424: Received loopback request without tag

    [9] 20091002073424: UDP: Opening socket on 0.0.0.0:60038

    [9] 20091002073424: UDP: Opening socket on 0.0.0.0:60039

    [9] 20091002073424: Resolve 8671: aaaa udp <PROXY_IP_ADDRESS> 5060

    [9] 20091002073424: Resolve 8671: a udp <PROXY_IP_ADDRESS> 5060

    [9] 20091002073424: Resolve 8671: udp <PROXY_IP_ADDRESS> 5060

    [6] 20091002073424: Sending RTP for 14bd5521@pbx#6b2fc5212a to <PBX_IP_ADDRESS>:51858

    [5] 20091002073424: Received incoming call without trunk information and user has not been found

    [9] 20091002073424: Resolve 8672: aaaa udp <PROXY_IP_ADDRESS> 5060

    [9] 20091002073424: Resolve 8672: a udp <PROXY_IP_ADDRESS> 5060

    [9] 20091002073424: Resolve 8672: udp <PROXY_IP_ADDRESS> 5060

    [9] 20091002073424: Resolve 8673: aaaa udp <PROXY_IP_ADDRESS> 5060

    [9] 20091002073424: Resolve 8673: a udp <PROXY_IP_ADDRESS> 5060

    [9] 20091002073424: Resolve 8673: udp <PROXY_IP_ADDRESS> 5060

    [7] 20091002073424: Other Ports: 2

    [7] 20091002073424: Call Port: 14bd5521@pbx#138323889

    [7] 20091002073424: Call Port: 61ffb548-b9af7923-fe7b9e36@10.1.1.110#7170d387ad

    [7] 20091002073424: Call 14bd5521@pbx#138323889: Clear last INVITE

    [9] 20091002073424: Resolve 8674: url sip:<PROXY_DOMAIN_NAME>

    [9] 20091002073424: Resolve 8674: naptr <PROXY_DOMAIN_NAME>

    [9] 20091002073424: Resolve 8674: srv udp _sip._udp.<PROXY_DOMAIN_NAME>

    [9] 20091002073424: Resolve 8674: a udp s-cscf-2.<PROXY_DOMAIN_NAME> 5060

    [9] 20091002073424: Resolve 8674: udp <PROXY_IP_ADDRESS> 5060

    [5] 20091002073424: INVITE Response 404 Not Found: Terminate 14bd5521@pbx

    [7] 20091002073424: Other Ports: 1

    [7] 20091002073424: Call Port: 61ffb548-b9af7923-fe7b9e36@10.1.1.110#7170d387ad

    [9] 20091002073424: Message repetition, packet dropped

    [9] 20091002073424: Resolve 8675: aaaa udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8675: a udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8675: udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8676: url sip:300@10.1.1.110:5060

    [9] 20091002073424: Resolve 8676: udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8677: url sip:501@10.1.1.204:5060

    [9] 20091002073424: Resolve 8677: udp 10.1.1.204 5060

    [9] 20091002073424: Resolve 8678: aaaa udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8678: a udp 10.1.1.110 5060

    [9] 20091002073424: Resolve 8678: udp 10.1.1.110 5060

×
×
  • Create New...