Jump to content
Vodia PBX forum


  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About cwernstedt

  • Rank
    Advanced Member
  1. Why isn't the below working? from-trunk:from trunk-ani (If coming from trunk, use from; otherwise use trunk-ani if configured.)
  2. 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-ani So 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,
  3. 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?
  4. 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, and are blocked as separate entities, so if 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...)
  5. 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
  6. 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?
  7. 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?
  8. 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.
  9. @Support I sent the numbers in a private message to you here on the forum.
  10. 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.
  11. 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";;false 103;Twilio (CH Office);;0*;"sip:+41\1@\r;user=phone";;false104;Twilio (CH Office);;5500*;"sip:+\1@\r;user=phone";;false105;Twilio (CH Office);;550*;"sip:+41\1@\r;user=phone";;false106;Twilio (CH Office);;+*;"sip:+\1@\r;user=phone";;false The setup works in v59.0
  12. 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?
  • Create New...