Jump to content
Vodia PBX forum

All Activity

This stream auto-updates     

  1. Today
  2. Yesterday
  3. Hello, Was testing some of the features for voicemails and while this is not critical or an issue per say, i felt like it should be brought up. So after listening to a voicemail you have various options, option 5 gives you the details of the calls. Before the new version it gave you the following information: Date of voicemail Time of voicemail The call From However with the new version the structure has changed: Date of voicemail Time of voicemail The call from The call To* Perhaps i haven't tested this in the correct environment it was designed for, but it seems redundant to let the user know that the voicemail left in their mailbox was left for their number. As an analogy imagine your personal cellphone voice tree announcing to you that "Voicemail 123 has been left for your number 456" Is there a way to modify this functionality or perhaps tweak it in some way.
  4. It's Debian64, but shouldn't make a difference though.
  5. No redirections. Just checked. Are you testing on a Win64?
  6. We replicated your agent group's setting here and everything is still the same. It works for us. We tried both 20 and 30 secs. You're sure you're not redirecting any of your extensions right?
  7. Exactly. I had it set to 20, and it seemed that it was close enough. But i used a stop watch and it's every 30 seconds.
  8. So we retry this at every 30 secs now ? Instead of 20 or 361 secs that you mentioned earlier?
  9. My apologies, it doesn't seem to follow the ring durations. It's at exactly 30 seconds intervals. See attached screenshots. Here are some logs that look off: [8] 11:14:08.889 Hangup: Call 668 not foundⓘ [7] 11:14:08.889 lookup_index error: Call port index is 668ⓘ [8] 11:14:08.889 Last message repeated 3 timesⓘ [9] 11:14:08.889 Using outbound proxy sip:xx.xx.xxx.xxx:55714;transport=tls because of flow-labelⓘ [7] 11:14:08.889 47 callids pendingⓘ or [9] 11:13:32.800 Traffic from ignored because of user-agentⓘ [9] 11:13:33.652 Resolve 121803: aaaa udp 49737ⓘ [9] 11:13:33.652 Resolve 121803: a udp 49737ⓘ [9] 11:13:33.652 Resolve 121803: udp 49737ⓘ [9] 11:13:34.662 Message repetition, packet droppedⓘ [9] 11:13:39.833 Last message repeated 2 timesⓘ [9] 11:13:39.833 Resolve 121806: udp 49789ⓘ [9] 11:13:41.326 Resolve 121808: aaaa udp 43083ⓘ [9] 11:13:41.326 Resolve 121808: a udp 43083ⓘ [9] 11:13:41.326 Resolve 121808: udp 43083ⓘ [9] 11:13:42.663 Message repetition, packet droppedⓘ [9] 11:13:46.674 Last message repeated 2 timesⓘ [7] 11:13:46.674 31 callids pendingⓘ [9] 11:13:46.674 Resolve 121809: aaaa udp 49737ⓘ [9] 11:13:46.674 Resolve 121809: a udp 49737ⓘ [9] 11:13:46.674 Resolve 121809: udp 49737ⓘ [9] 11:13:46.675 Resolve 121810: url sip:555@;line=eogked7iⓘ [9] 11:13:46.675 Resolve 121810: udp 49737ⓘ [9] 11:13:50.666 Message repetition, packet droppedⓘ [9] 11:13:54.948 Last message repeated 2 timesⓘ [9] 11:13:54.948 Resolve 121814: udp 29261ⓘ [8] 11:13:55.119 Last message repeated 8 timesⓘ [7] 11:13:55.119 Port 670: Clear last INVITEⓘ [5] 11:13:55.119 INVITE Response 408 Request Timeout: Terminate cc620b26@pbxⓘ [7] 11:13:55.119 lookup_index error: Call port index is 670ⓘ [8] 11:13:55.119 Hangup: Call 670 not foundⓘ [9] 11:13:55.120 Using outbound proxy sip:;transport=tls because of flow-labelⓘ [9] 11:13:55.120 Resolve 121816: url sip:555@;line=eogked7iⓘ [9] 11:13:55.120 Resolve 121816: udp 49737ⓘ [9] 11:13:55.121 Resolve 121818: url sip:555@;line=eogked7iⓘ [9] 11:13:55.121 Resolve 121818: udp 49737ⓘ [9] 11:13:55.121 Last message repeated 2 timesⓘ [7] 11:13:55.121 Port 672: Clear last INVITEⓘ [5] 11:13:55.121 INVITE Response 408 Request Timeout: Terminate 8ee95a84@pbxⓘ [7] 11:13:55.122 Port 673: Clear last INVITEⓘ [5] 11:13:55.122 INVITE Response 408 Request Timeout: Terminate be778a5a@pbxⓘ [7] 11:13:55.123 lookup_index error: Call port index is 672ⓘ [8] 11:13:55.123 Hangup: Call 672 not foundⓘ [9] 11:13:55.123 Using outbound proxy sip:;transport=udp because of flow-labelⓘ [9] 11:13:55.123 Resolve 121819: url sip:;transport=udpⓘ [9] 11:13:55.123 Resolve 121819: udp 49789ⓘ [5] 11:13:55.124 SIP Txⓘ
  10. You mentioned that you saw this happen every 20 secs to we let it ring for 40 something secs. Fine, we'll make it ring longer this time. And then try to pick the call. We have both Snom's here.
  11. Did you let the phones ring over several ring durations? For example, let it ring 361 seconds in the above example, it will show 4 calls on my phones. I tried with a Snom and a Yealink. In the active calls lists it only shows 1... I checked that too.
  12. Can you tell us where exactly are you seeing the number of calls being increased? Because we tried with your setup and ours too, but we couldn't reproduce the issue on 64.0. The number of calls was always 1 on both the agents and in active calls list. And when we picked up either of the phones up, it stopped ringing. Maybe there's a redirection involved in your scenario?
  13. Last week
  14. We are testing on 64.0 and it seems there's something wrong with the agent group. The agent group now opens a new call after every call duration. For example. Say someone calls into the agent group, and the stage duration is 20 seconds. It will ring for 20 seconds, add a new agent, and then it will show up as 2 calls the phone. After another 20 seconds, 3 calls are active, 20 seconds later, 4 calls, and so on... When picking up, it doesn't do anything. You just need to pick up the latest call in order for it to hear the person. So you need to go through all, and hangup until you reach the last call. The Active Calls list shows 1 call only. Was working fine in the older versions. This example says 90 seconds, but I tried with 20 seconds.
  15. So you want to move to another agent after 10 seconds?! In that case the hunt group would indeed a better (and easier) solution.
  16. Hi Taner, our client requirement is not 60 seconds it's 10 seconds so we can not putt it on 60 seconds. Thanks
  17. You can edit web page codes and set 60 seconds. Take care, Taner
  18. Really sorry but can you please advise on it ASAP if it's doable or not? We need to tell the client. Thanks
  19. I tested but still not working. It keeps ringing on prior agents. We can not set the ring stage duration to 60 seconds. Maximum we can is 10 seconds. This is our client requirement. By the way I'm at version 63.0.5.
  20. ah ok, I thought I was a visionary
  21. Hmm maybe some problem with the 64.0 build - we found a few other glitches will patch that into 64.0.1 soon.
  22. Set the number of agents per stage to 1 with a long stage duration (e.g. 60 seconds) and then turn the option "Allow multiple calls to ring agents in parallel" on.
  23. Hi Tanerul, I think this is not good option to go via Hunt Group or Rotate agent groups. Anyone else please advise.
  24. Hi Ramesh, there's no option for that. You can use Hunt groups OR use different agent groups for every agent and forward the call between groups for similar effect. take care, Taner
  25. If you're unable to accomplish this, please create a ticket on vodia.zammad.com and give us the following details: 1. Your admin login to your PBX.2. Name of the domain having issues.3. Name of the domain where your trunk is.4. Name of the trunk.5. Number to dial to test to replicate this issue.
  1. Load more activity

  • Who's Online (See full list)

    There are no registered users currently online

  • Create New...