cwernstedt
-
Posts
103 -
Joined
-
Last visited
Content Type
Profiles
Forums
Events
Posts posted by cwernstedt
-
-
I assume it's the mailbox, since there is no agent group configured, but mailbox doesn't explicitly offer callback as an option, and "offer camp on" is disabled.
The sequence of events from the point of view of the caller seems to be like this:1) caller places a call to the extension
2) Ring tones are generated .
3) "Something" (probably voicemail) at the PBX picks up and it immediately (before even playing a greeting) for unknown reasons adds the caller to the callback list.
4) The caller hangs up.
From the callee's point of view, the phone rings, but when picking up, it's the PBX offering various options. Not sure what it is. (See the file rec_115_13.wav in the attached ZIP. I'm also attaching PCAP files captured on the PBX.)
When this happens there is always two calls registered in the log, starting at the same time.
A big question is if the callback list option can somehow be triggered before the mailbox has kicked in . It almost appears to be the case, because the mailbox really shouldn't have come into play here. (The callee account had a live registration generated by Counterpath, and the callee picked up well before the call should have landed in voicemail.)
-
Looks like I'm closer to pinning down what's going on... Seems like my test call generator, somehow, sometimes, manages to make some noise that is misinterpreted as the starcode that gets the call added to the callback list.
I wonder, what are the conditions for this feature to be activated by a caller? Can it, for example, happen only when the caller reaches the mailbox, or is there some other situation when it can happen, such as when ringtones are being generated before the callee or voice mail has picked up? Can the feature be turned off?
-
The setup is now the standard one where the client and the registration server alternate registrations, but potentially with some brief overlaps (option 0 below). Not sure this is what is causing problems since Vodia supports multiple registrations for the same account, and since most of the time, the handover appears to work fine.
In any case, seems like you are suggesting that 2 would be more stable?
/CW- 0: Standard: Your VoIP service provider supports multiple registrations. In this mode, there may be short overlaps of registration where both the Push server and the Bria client are registered to the SIP server.
- 1: Single Device Emulation: Your VoIP service provider does not support multiple registrations. Bria and the Bria Push server must unregister before the other one can register.
- 2: Continuous: Your VoIP service provider support multiple registrations. The Bria Push server is always connected to the SIP server. Bria is only connected to the SIP server when Bria is in the foreground. When Bria is in the foreground, Bria ignores push notifications so you do not receive duplicates.
- 3: Single Device Takeover: Your VoIP service provider does not support multiple registrations. Bria and the Bria Push server take over registrations from each other without unregistering first.
-
Thanks! Upgraded with no issues, and could restore PRACK after that.
A remaining problem with Counterpath and its push/handover mechanism is that some calls behave very strange. Every now and then this happens:
The caller lands in voice mail, but the Bria Stretto user will hear the phone ring.If picking up, the callee will hear nothing OR will hear what seems to be the Virtual Private Assistant.
The PBX registers these calls as two calls in the call history.
I wonder what can be done to troubleshoot this.No trunks are involved. This is just between registerred SIP-clients and the PBX.
-
Ok. Excellent. I have hesitated to upgrade because I don't want to break anything that is working, but maybe 63 is a safe one? Rolling back seems difficult due to the password encryption.
-
FYI everyone: PRACK needed to be turned off for CounterPath's push solution to work with v62.0.1.
(Not sure if this will have some unforeseen consequences as I have only tested successfully twice.) -
Regarding CounterPath as an alternative for iOS clients, I wonder if the Voida PBX supports CounterPath's handover model for receiving calls when the client is not in the foreground.
The way it is supposed to work is described here: https://www.counterpath.com/assets/docs/guides/mob/mob_Retail_Ios_5.5.3/UG/Default.htm#clients/UserGuides/Mobile/Reference/mobBriaPushService.htm .
However, with Vodia PBX v62.0.1 I can't get this to work "out of the box" at lest. The PBX sends caller to voice mail if no other extensions are registered, maybe due to some unexpected behavior of the Bria Push Server.
Would be nice if this could work. -
Why isn't the below working?
from-trunk:from trunk-ani
(If coming from trunk, use from; otherwise use trunk-ani if configured.)
-
Hi,Your suggested string (the below) causes the ANI from externally originating calls to now show (instead some other ANI is shown, extension or trunk )from-cell:ext-ani from-cell:ext-ani from-cell:dom-ani from-trunk:from acd-ani ext-ani trunk-prefix dom-ani trunk-aniSo from our point of view the same as having nothing in the Regular ANI rule field.This string, on the other hand, causes the same bad behavior as before (internal extension numbers are presented as ANI to the PSTN) :
from-trunk:from acd-ani ext-ani trunk-prefix dom-ani trunk-ani
Note that this is the same as your rule, but with the from-cell clauses removed.Why from-cell clauses in the rule field changes behavior in this way at all is a mystery as none of the test calls originate from a user’s cell phone. They originate from either an internal extension or from some random external number.It looks like something is seriously wrong with the code here with regard to the parsing of the ANI rule field.Note that what I’m trying to do worked perfectly before and this isn’t a weird scenario. (One would certainly want to pass on the original ANI if the trunk provider is OK with it.)Cheers, -
When upgrading from 60 to 62.0, ANI behavior stopped being good, I'm not sure how to make it work.
Desired behavior (worked with version 60):1) If the call originates from trunk, then the original caller ANI should be used when calling out to an extension's cell phone .
2) if the call originates from internal extension then the extension's (if available) or the trunk's ANI should be used instead.
I'm trying to make it work with v62, but whereas the ANIs of calls originating from a trunk are presented correctly, calls from internal extensions are presented incorrectly (the internal account number is presented instead of the extension's outbound number ANI or the trunk ANI . (So all calls from say, internal extension 999 would be presented as 999 instead of say +46314343455.)
On the trunk I'm trying this setting which seems logical to me:ani_regular: from-trunk:from trunk-ani
I needed to put in "from-trunk:from" to make criteria #1 above work, but this also results in the bad behavior for calls from internal extensions.
How can I replicate the behavior of v60 so that things work again? -
Is there a way to get automatic blacklisting to block all attempts from an offender IP address instead of blocking IP+originating port as separate instances?
As it is now it appears that, say, 46.166.151.43:5137 and 46.166.151.43:5151 are blocked as separate entities, so if 46.166.151.43 tries with thousands of other additional originating ports, the black list will be filled with thousands of entries. (Plus my email address being hammered with thousands of notifications...)
-
-
Is there a way to periodically and automatically change the participant access code (PIN) of a conference using a script that accesses the API or manipulates settings files?
It's an "ad-hoc" conference that users regularly access.
I have studied the API documentation, but I can't find the name of the attribute to change, and it's unclear if a new access code can be submitted via the API at all.
/CW
-
OK.
I think to move things forward a bit faster than trial and error, I should pay for some consulting from someone skilled with setting up auto-provisioning with Snom and Vodia. (Should be fairly standard scenario.)To make this happen, do you recommend that I purchase some premium support tickets?
-
I don't PnP the phone yet. It's not in the same LAN as the PBX so not sure how to do it properly at this point, but I'd like to solve this when the installation grows.
Is PnP necessary for as-feature-event subscription?
-
Is DND state syncing between snom D785 and Vodia 60.0.2 supposed to work?
using_server_managed_dnd1=on
...but state changes on the PBX don't show up on the phone.
-
10 hours ago, Support said:
Hi,
Can you send us both the numbers, so that we can test it on our 60.0 here with your dial plan mentioned above? +6421NNNNNN and +6427NNNNNNN ?
@Support I sent the numbers in a private message to you here on the forum.
-
34 minutes ago, Vodia PBX said:
Sounds like a problem with the trunk settings to me. Try filtering in the LOG for the IP address of the SIP trunk provider; there should be some kind of error message on what they don't like.
I couldn’t find any SIP messages going out to the trunk when the particular cell phone number is used. SIP messages were sent when the working number was used.
-
3 hours ago, Support said:
Hi,
Can you send us both the numbers, so that we can test it on our 60.0 here with your dial plan mentioned above? +6421NNNNNN and +6427NNNNNNN ?
Sure, I’ll do that.
-
I'm trying out the 60.0.1 release.
Having some trouble:
- Cell pone redirect for an extension (114) to a certain number (+6421NNNNNN) stopped working.
- Calling +6421NNNNNN from the 114 extension works.
- Cell pone redirect for the extension works when set to a different but similar number (+6427NNNNNNN) .
Note that the number that works has more digits than the number that doesn't work.
It is not likely that the issue is with the outgoing trunk, because the log doesn't indicate any INVITE messages sent through the trunk when 114 is called and cell phone is set to +6421NNNNNN , and the trunk operator (Twilio) doesn't log any attempts or errors.Dial Plan used by 114:
101;Twilio (CH Office);;00*;"sip:+\1@\r;user=phone";;false103;Twilio (CH Office);;0*;"sip:+41\1@\r;user=phone";;false
104;Twilio (CH Office);;5500*;"sip:+\1@\r;user=phone";;false
105;Twilio (CH Office);;550*;"sip:+41\1@\r;user=phone";;false
106;Twilio (CH Office);;+*;"sip:+\1@\r;user=phone";;falseThe setup works in v59.0 -
-
One of our operators, Twilio, says it's OK with our PBX "spoofing" the CID when calling out on their trunks for as long as the CID belongs to someone calling into their system.
This would enable us to forward the actual originating CID to our cell phones.
Caller (CID#1) --> Twilio Trunk --> PBX --> Twilio Trunk -> Cell phone (sees CID#1)
However a caveat is that CIDs from calls originating from non Twilio trunks as well as from internal extensions should not be spoofed (or can't be spoofed).
I'm uncertain about how to configure trunks properly for this scenario.
Any ideas?
-
I have a similar problem to the one discussed above.
I need to differentiate between calls coming in on two trunks to the same provider (Twilio). One trunk as defined on the Twilio side enforces TLS at extra cost, but I don't want all incoming calls from Twilio to go via this trunk.
Is there a way that I can make the PBX route Invites like the two below to different trunks?
Invite version 1 (I want this to go to the first trunk):
QuoteINVITE sip:+4xxxxxxx1908@YY.ZZ.99.123 SIP/2.0Record-Route: <sip:54.171.127.192:5060;lr;ftag=62103213_6772d868_bb1c95c2-3144-4e70-a476-d42f0f970ff7>Max-Forwards: 17From: <sip:+11234567890@imp.pstn.twilio.com>;tag=62103213_6772d868_bb1c95c2-3144-4e70-a476-d42f0f970ff7To: <sip:+4xxxxxxx1908@YY.ZZ.99.123;user=phone>CSeq: 102 INVITEDate: Wed, 31 Jan 2018 06:00:58 GMTP-Asserted-Identity: <sip:+11234567890@10.41.27.13;user=phone>Diversion: <sip:+4xxxxxxx1908@public-vip.ie1.twilio.com>;reason=unconditionalCall-ID: 8e10d24703ba26d98b9b01f25b9b21af@0.0.0.0Via: SIP/2.0/UDP 54.171.127.192:5060;branch=z9hG4bK46f8.0e6eb963.0Via: SIP/2.0/UDP 172.18.200.223:5060;rport=5060;received=172.18.200.223;branch=z9hG4bKbb1c95c2-3144-4e70-a476-d42f0f970ff7_6772d868_239-2322326987040813616Contact: <sip:+11234567890@172.18.200.223:5060;transport=udp>Allow: INVITE,ACK,CANCEL,OPTIONS,BYEUser-Agent: Twilio GatewayX-Twilio-AccountSid: ACd686a3ed4302bdf2710a152470c1f784Content-Type: application/sdpX-Twilio-CallSid: CAd5607e4384a06de577a9287c7856b152Content-Length: 234Invite version 2 (I want this to go to the second trunk)
QuoteINVITE sip:+4xxxxxxx1890@YY.ZZ.99.123 SIP/2.0
Record-Route: <sip:54.171.127.193:5060;lr;ftag=41806496_6772d868_121fab86-2cd0-40e4-ac41-4e49a738a7af>
Max-Forwards: 17
From: <sip:+11234567890@imp2.pstn.twilio.com>;tag=41806496_6772d868_121fab86-2cd0-40e4-ac41-4e49a738a7af
To: <sip:+4xxxxxxx1890@YY.ZZ.99.123;user=phone>
CSeq: 102 INVITE
Date: Wed, 31 Jan 2018 05:59:15 GMT
P-Asserted-Identity: <sip:+11234567890@10.41.27.13;user=phone>
Diversion: <sip:+4xxxxxxx1890@public-vip.ie1.twilio.com>;reason=unconditional
Call-ID: 94fec472857dc4655684f999ea503326@0.0.0.0
Via: SIP/2.0/UDP 54.171.127.193:5060;branch=z9hG4bKaa2.5b5bc56.0
Via: SIP/2.0/UDP 172.18.198.129:5060;rport=5060;received=172.18.198.129;branch=z9hG4bK121fab86-2cd0-40e4-ac41-4e49a738a7af_6772d868_291-4899177849831067392
Contact: <sip:+11234567890@172.18.198.129:5060;transport=udp>
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE
User-Agent: Twilio Gateway
X-Twilio-AccountSid: ACd686a3ed4302bdf2710a152470c1f784
Content-Type: application/sdp
X-Twilio-CallSid: CA66db5e8d50d2417ebab867afa6408700
Content-Length: 238
-
As it turned out, I had forgotten to put in all of the local networks in the IP Routing list under SIP settings.
Like this: (covers all private address spaces)
10.0.0.0/255.0.0.0/[PBX private IP address] 172.16.0.0/255.240.0.0/[PBX private IP address] 192.168.0.0/255.255.0.0/[PBX private IP address] 0.0.0.0/0.0.0.0/[PBX public IP address]
The amazing and puzzling thing is that things worked at all from misc networks in the 10.0.0.0- series before this change.
when will the Apple App be ready?
in Android App
Posted
Initiate call back after hangup is "No" for the called extension in the tests and the calls are not made from a cellphone or POTS-phone, but from a registered extension.