Jump to content

youneeq

Members
  • Posts

    17
  • Joined

  • Last visited

Posts posted by youneeq

  1. It looks like this was somewhat fixed but now when you delete one or more messages from a mailbox an updated MWI header with the updated ratio of new to old messages is not sent. I'll try to submit another beg report I suppose.

  2. By this time the NCH team has developed the codes to correct the IVM bug.

     

    Hi Graig, so you are confirming the bug is fixed? If so, that's great. What version off IVM so I can check it out?

  3. Hi,

     

    IVM does have Message Waiting Indicator Support - at this time it has only been thoroughly tested with Axon - only limitation is your light will stay on as long as there are messages in your IVM mailbox folder, so if you get your voicemails by email attachment, you would have to use the "delete after sending" option in IVM for the MWI light to be accurate.

     

    FI/FO is a suggestion for next release.

     

    The current code recognizes a call as private if it does not begin with a digit, it is being modified to allow for the '+' sign. We should be able to get this released fairly soon.

     

    Hope this helps.

     

    DJ

     

    Hi DJ,

     

    Looks like you guys took care of the "+" prefix bug in the latest IVM 5.03 beta. Thanks!.

     

    But! The MWI still does not work correctly in IVM 5.03. I've submitted a bug report for you guys explaining it. I'll post here for anyone else's benefit.

     

    IVM's SIP NOTIFY message logic is not consistent. When IP phone sends SUBSCRIBE message, IVM sends proper NOTIFY message including "Voice-Message: 1/0" header but if IVM receives a new voicemail it then sends a NOTIFY message but missing the "Voice-Message: 2/0" header. So the registered IP phone does not get updated with the total new message count from IVM. If the IP phone sends a SUBSCRIBE then IVM will properly send the updated "Voice-Message: 2/0" header. It should send this header all the time.

     

    Here's examples of working and non-working trace from IVM.

     

    After IP phone SUBSCRIBE is sent:

     

    19:59:22 UDP Packet Sent to 10.1.2.219:36390 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    NOTIFY sip:101@10.1.2.219:36390;transport=udp SIP/2.0

    Via: SIP/2.0/UDP 10.1.2.212:5061;rport;branch=z9hG4bK193788

    To: "phone"<sip:101@10.1.2.212>;tag=bb0eff73

    From: "phone"<sip:101@10.1.2.212>;tag=21

    Call-ID: NWMzNzIzM2QzODBiMjVjNmIwYjU0YWUxMDk1ZDE0Zjc.

    CSeq: 243 NOTIFY

    Max-Forwards: 20

    User-Agent: NCH Software IVM Answering Attendant 5.03

    Contact: <sip:199@10.1.2.212:5061>

    Event: message-summary

    Subscription-State: active

    Content-Type: application/simple-message-summary

    Content-Length: 80

     

    Messages-Waiting: yes

    Message-Account: sip:101@10.1.2.212

    Voice-Message: 1/0

     

    ----------------------------------------------------------------

     

    After leaving new voicemail:

     

    20:03:49 UDP Packet Sent to 10.1.2.219:36390 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    NOTIFY sip:101@10.1.2.219:36390;transport=udp SIP/2.0

    Via: SIP/2.0/UDP 10.1.2.212:5061;rport;branch=z9hG4bK203788

    To: "phone"<sip:101@10.1.2.212>;tag=bb0eff73

    From: "phone"<sip:101@10.1.2.212>;tag=21

    Call-ID: NWMzNzIzM2QzODBiMjVjNmIwYjU0YWUxMDk1ZDE0Zjc.

    CSeq: 244 NOTIFY

    Max-Forwards: 20

    User-Agent: NCH Software IVM Answering Attendant 5.03

    Contact: <sip:199@10.1.2.212:5061>

    Event: message-summary

    Subscription-State: active

    Content-Type: application/simple-message-summary

    Content-Length: 80

     

    Messages-Waiting: yes

    Message-Account: sip:101@10.1.2.212

    Missing this header ----> Voice-Message: 2/0

  4. Hi DJ,

     

    Did anyone confirm and/or fix the bug? I can't imagine it's a huge change in code. I'd really like to be able to block the phone spam.

     

    Thanks,

    youneeq

     

     

    Hi Casual,

     

    Thank you. I have submitted this to our development team for testing. I will also make sure that MWI and FI/FO VM playback are listed as product suggestions.

     

    DJ

  5. Hi, Isubmitted a bug report recently and have heard nothing back, so I'm posting on here as well, also in case other ppl have run into the same issue... In IVM 4.11 (my version) and confirmed in the latest 5.02, when "Caller Blocking" is checked and "Block private or unknown numbers" is checked and a SIP call comes in with CID prefixed with +1 it always gets blocked. It's interpreting these numbers as private or unknown when it shouldn't be.

     

    Also, is IVM/Axon ever going to get MWI support? And an option to be able to playback voicemails in first in/first out order would be great. Thanks!

  6. Yeah, I can't get this to work on IVM v4.11 either. I get "Encryption required for requested Email server. Please check your Email Settings." Whether you append the port number or not.

     

    NCH...?

  7. Magic Jack works with Asterisk though...

     

    Im working with stabler now..

     

    http://www.trixbox.org/forums/trixbox-foru...erisk-magicjack

     

    ran in to him on freenode. small world.

     

     

    We did need to know the user agent of the MJ Device. That might be the uniqueness you were referring to that won't let IVM work.

     

    I wish it could work :(

     

    IMW, I have magicJack (MJ), IVM, Axon, and IMS working together since about May '08. Works fine other than MJ's music on-hold (yes, they actually have MOH) overides IMS' MOH. And possibly hold/xfer is not always 100% reliable. Not sure if it's MJ or Axon/IVM. I've caught Axon communication bugs before. So to get around that I use VoiceStick 6/29/10 Edit: Now I use Voip.ms. You have to disable their MOH through their website interface so it doesn't overide yours. DID for inbound calls. Then IMS MOH works with VoiceStick and hold/xfer is 100%. MJ inbound/outbound works great otherwise. You must use the SIP credential and proxy tool(s) out there to get around the stupid user agent/nonce SIP registration measures they have put in place as of 06/09/09 I believe was the date they enabled it. magicJack, if you read this, please offer BYOD!

  8. I had it working for about the last year until MagicJack (MJ) just implemented changes to their pbx servers as of June 9th. Now for the most part they are blocking anyone from using any IP PBX, etc. but their USB dongle. I'm hoping it's only a matter of time before hackers figure out just like the last few times. Also, MOH (music on hold) does not work with them; at least provided from your end. They have they're own which plays instead of yours when you put a call on hold. It's a loop of an instrumental version of Aerosmith's Dream On and a few other songs. I just got a Voicestick (VS) Next2Nothing (or whatever it was called) plan for my inbound callers and I use MJ for outbound. My MOH works with VS.

     

    Only problem with the VS inbound calls is Axon doesn't handle the SIP headers and drops the call when I go to answer my extension with my softphone. (At least as of Axon version 2.01)

  9. For me it turned out to be VoIP providers as far as I could tell. With Voicestick the inbound caller hears my MOH. With Magicjack they get silence or get to listen to Magicjack's hold music but not mine. That's actually why I have the Voicestick account so I can provide my own MOH. I think either some VoIP providers block it, don't support it, or are not compatible with Axon. Maybe I'll look at my SIP traces and see if I can find a difference/problem. I know right now there is a bug with Axon that NCH is working on that causes my transferred calls to get dropped when an inbound call comes in from one VoIP provider but not the other. Maybe you guys can post SIP trace logs and someone compare them and figure it out. (I'm no SIP pro, though) Just a thought.

  10. Hi nchaj,

     

    Thanks for the response. Just that alone helps. I understand it's not an agreement. I feel it's more a common courtesy especially with your paying customers.

     

    If you need any help testing let me know. I can also loan you the VOIP acct credentials for your internal testing if it helps move things along.

     

    I'll point out that your Express Talk product somehow ignores this Axon bug and suprisingly still answers the INVITE even with the missing end of the SIP address so there might be a small issue with the programming logic on that product too. Just letting you know.

     

    I await the fix.

     

     

    Regards,

    youneeq

     

     

    we have a fix and are testing now. You will be notifed when tested and all ok. Of course we want to hear about bugs but reporting a bug has no agreement of reply or immediate fix.
  11. Hi,

     

    It's been 3 days since the bug report I submitted to NCH and 2 days since posting it on this forum. I have supported your company by purchasing over $400 USD of licensing (including Axon) and no response yet by e-mail, phone, or post on this forum. (I also checked my spam folder) This bug is causing all my inbound calls from Voicestick to route to VM because Axon is corrupting the original SIP address and my softphone CounterPath Bria can't answer. Do I need to dispute the charges with my credit card company and get my hard-earned money back from you guys?

     

    You can also reference a similar post about the Axon SIP address bug here: http://support.counterpath.com/viewtopic.p...3e9046c4b3a44eb

     

    I'll give it a few more days before I take the next step.

     

    Thanks for your time,

    youneeq

  12. Hi,

     

    Looks like Axon PBX is dropping the end part of the SIP address ";user=phone" and leaving off the final ">" See bolded SIP addresses below.

     

    06:18:12 UDP Packet Sent to 72.5.80.116:5060 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    ACK sip:72.5.80.116 SIP/2.0

    Via: SIP/2.0/UDP xxx.xxx.78.148:5060;rport;branch=z9hG4bK423208

    To: "1234567890" <sip:1234567890@72.5.80.113:5060;user=phone>;tag=GR52RWG346-34

    From: "xxxxxxxxxx@i2telecom.com" <sip:xxxxxxxxxx@i2telecom.com:40893>;tag=7757

    Call-ID: 618132008-83465E0518192906301@72.5.80.113

    CSeq: 340 ACK

    Max-Forwards: 20

    User-Agent: NCH Swift Sound Axon Virtual PBX 2.00

    Route: <sip:72.5.80.113:5060>

    Authorization: Digest username="xxxxxxxxxx",realm="72.5.80.113",nonce="F71D13EE5277BEC0304A83024AB824F0",uri="sip:72.5.80.116",response="d8b840a3755a5f8de4e7d8b05b7bbe98",opaque="2BCC2DB101990D646A20ECB43326C8DA",algorithm=MD5

    Content-Length: 0

     

     

    ----------------------------------------------------------------

     

    06:18:12 UDP Packet Sent to 192.168.1.8:18152 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

    INVITE sip:101@192.168.1.8:18152;rinstance=20d8b85696b4b9ab SIP/2.0

    Via: SIP/2.0/UDP 192.168.1.3:5060;rport;branch=z9hG4bK433208

    To: <sip:101@pbx.domain.com>

    From: "1234567890" <sip:1234567890@72.5.80.113:5060;tag=7759 <----Missing end bracket

    Call-ID: 1214733862-3208-pbx@xxx.xxx.78.148

    CSeq: 953 INVITE

    Max-Forwards: 20

    User-Agent: NCH Swift Sound Axon Virtual PBX 2.00

    Contact: <sip:101@192.168.1.3:5060>

    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, INFO, REFER, NOTIFY

    Supported: replaces

    Content-Length: 0

×
×
  • Create New...