Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 32

Thread: Quadro 2xi & Thomson ST2030

  1. #11

    Default

    I'm not affraid, actually I'd be glad if you did... here's the URL :
    http://espace-temps.dnsalias.org:8001/
    (only your IP have access)

  2. #12
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    I looked on your board and now I understand why the streams are proxied through Quadro - this is the "automatic" RTP proxy mode introduced lately: if the target and the destination are in the different subnets, Quadro opens RTP proxy automaticatty, regardless of the RTP Proxy setting on Routing rule or anywhere else. This is done to avoid problems with missing audio, and actually this works in your case (as you will not hear the audio, if there is no RTP proxy).

    Apart of that, I am still not sure what can cause the problem on your device.
    I can see there only two problems:
    a) you could have accidental outages one or two times per day for several minutes up to one hour (we are working now to find the problem);
    b) you have one call in the call stats with terrible call statistics (with length of 22 min and with about 30% of lost packets; also the codec is shown wrong on that call). Typically such stats mean that there are lost RTP streams in your network. Not sure which device is sending them.

    Is it possible to have an RTP capture for such bad calls? As soon as you hear the conversation is going bad, you can open the "netcapture.cgi", and start the capture on the WAN interface. This could show what streams are passing by at that moment, and also can show some parameters of RTP stream. It seems that the RTP statistics is not enough to resolve this. Also (or alternatively) if you give an access to the port 645 on your Quadro, I can run remote logging, to see if something strange was happening on the device on the moment when bad call occured.

  3. #13

    Default

    Thanks for your going that deep into this.
    I have opened the port 645 (TCP) for you, that is for your public IP.
    I will try to get a capture, though it might be tricky to have the customer call me when it happens and keep the call going at the same time... We'll see. I don't know what kind of logging you get through port 645, but if there's a long enough history it might be easier to use since the users usually report problems to me after they happen.

  4. #14
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    I have started remote monitoring from the port 645. Lets try to catch the problem together.

    Related to the outages you have on that device (I can clearly see tey are happening, though you didn't complained about them): this have started in September, probably something is changed in the confid at that time. The possible reason of that problem is those two settings:
    1. One or more of the phones are using TCP
    2. The SIP timers are set to "High Avalilability"

    Is it possible to fix one of this factors to see if the second one still causes the issue? For example, change the settings on the phone to use UDP (this should be the default), or set the timers to "RFC3261"?

  5. #15

    Default

    The specific outages you are referring to are probably failed outgoing calls to ITSP. They began appearing when I set the phones to use TCP, so I have now reverted back to UDP.
    I will change the timer settings to RFC3261.
    Can you keep the monitoring going until I get a timestamp of the problem from the user?
    Thanks again,
    R.

  6. #16
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    Yep, the monitoring is still ON and we can keep it running for about one-two weeks, if necessary. Anyway, please try to get netcapture ("all packets" on WAN), even if the call is closed, as even if you get that in 20-30 minutes, it could containg the lost strem, if any).
    BTW, I can see that some of your phones still use TCP. Please don't change this, so we can see if the "High Availability" timers were causing the problem (now you have RFC3261 timers set).

  7. #17
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    One more suggestion: if it is hard or absolutely impossible to make a network capture of the bad call (this is the only thing actually, which will surely give an idea on what is happening), at least it worth to make a VM recording of such call.
    This can be done the following way (you can tell users how to do that, so they can do thatt themselves):
    1. Create a special extension for recording, with at least 1% of user space attached. Or use an existing extension with VMbox. Lets assume that is extension 11.
    1. Create a routing rule, like 55555, NDS=5, Prefix=11, with a PBX-Voicemail type.
    2. When problematic call occurs, user can hold, call to 55555, connect to VMbox of extension 11, then press Conference button. This will establish a conference call between those two parties and the VMbox of extension 11. So the conversation will be recorded to the VM box.
    3. We can look later to this mail to: a) find that call in the statistics based on the caller/time info; ; b) listen to see which type of distortion is there.

  8. #18

    Default

    Ok, I have had two bad calls:
    Outgoing calls from ext 38 to 015369xx55 and 024067xx37, on the 18th of septembre, I don't have the exact time but it was before 1:08PM. Choppy sound on the inside end, maybe other end as well. For some reason outgoing call don't appear in the call log...?!

  9. #19
    Quadro Architect
    Join Date
    Jun 2006
    Location
    Around myself
    Posts
    2,075

    Default

    I found both calls in the Call Stats: one of them is about 26 minutes long (started at 11:32:28) and marked as "Very bad", another is 2 min long (started at 12:04:16) and maked as "Bad".
    It looks there are two (at least) completely different problems there:

    1. The first call is not really "Very Bad" as it marked in the call stats. If it were so bad, as it shown, it woulnt last 26 minutes What really happened at that call is the following: you have "SIP session timer" enabled. After 15 minutes, the Quadro initialed session refresh, as a result of which (due to some specifics of Thomson phone operation), the connecteion was closed and reopened again with G.729 codec (the original codec was PCMU). So user may experience some click in the middle of conversation (at about 15 minutes), and probably the voice quality became worse after that (as it switched to from PCMA to G.729). But the quality was not very bad, as the person continued to talk for another 11 minutes.
    To avoid that kind of problems you should either switch OFF the "Session Timer" at the "SIP Settings" page (this will help for sure), or change the codec preference on the Thomson phones to exactly match the prference list on the Quadro: it should have the same order (this should help, though I have no 100% guarantee, as this is up to Thomson phone behaviour).

    2. The second bad call happened purely due to the newtork connection dropdown at the end of that call. If you look at the call stats, you will see another call on 12:07:49 (from ext.36 to the same ITSP), which had the "satisfactory" call rating, which means the call was also not good. It looks like either your ISP had some short period of bad connection in general, or the connection to the "freephonie" ITSP gone bad at that moment.
    So this looks like a WAN network connect short outage, which is restored itself after some time.
    Or the ITSP has network connection problems

  10. #20

    Default

    HELP !
    Right now users can't place outgoing calls nor receive incoming calls (not even call internal phones!)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •