1/2 second delay on audio with E1752C

[suboxes]

First off I want to thank everyone who has worked to put this project together. I have finally things setup to be working quite well especially in comparison to chan_mobile. Inbound and outbound Voice/SMS working and I Iove the fact that SMS can be sent and received while on a call. The only question I had was is the 500ms delay normal or is it just a problem with the E1752C's? Are there any tweaks that can be done to limit the delay? Sound quality is great-besides the delay and the connection seems to be stable (test call has been going 2 1/2 hrs no issues). I am currently running Asterisk 1.8.10.0 on Linux debian 2.6.32-5-686. I tried to run chan_dongle on latest PBX in a Flash which runs on CentOS but I was getting one way voice and the recommended driver to fix one way voice would not compile. Any recommendations or suggestions would be appreciated. As a side note I could not get chan_dongle to compile on ArchLinux.

[Alejandro]

I have 4 1752's working with no delay. Try a different usb port, maybe you are having some kind of issue there. For sure this particular model works great, no delay, excellent audio quality, a very fast response on setting up a call or hanging it up.

El 13/03/12 18:39, suboxes escribió:

[Andrew Geddes]

Alejandro,

Thanks for the reply. What distro and kernal are you using for your Asterisk server? This is not in production as of yet so I am just working out the bugs and any suggestions would be great. Here is what shows up in dmesg for my Huawei dongle:

[19108.888061] usb 1-2: new high speed USB device using ehci_hcd and address 3

[19109.022559] usb 1-2: New USB device found, idVendor=12d1, idProduct=1001

[19109.022574] usb 1-2: New USB device strings: Mfr=3, Product=2, SerialNumber=0

[19109.022587] usb 1-2: Product: HUAWEI Mobile

[19109.022597] usb 1-2: Manufacturer: HUAWEI Technology

[19109.025252] usb 1-2: configuration #1 chosen from 1 choice

[19109.030240] option 1-2:1.0: GSM modem (1-port) converter detected

[19109.030583] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB0

[19109.031480] option 1-2:1.1: GSM modem (1-port) converter detected

[19109.031770] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB1

[19109.033358] option 1-2:1.2: GSM modem (1-port) converter detected

[19109.033678] usb 1-2: GSM modem (1-port) converter now attached to ttyUSB2

CPU usage is low with active calls:

top - 16:50:25 up 15:58,  1 user,  load average: 0.00, 0.00, 0.00

Tasks:  73 total,   1 running,  72 sleeping,   0 stopped,   0 zombie

Cpu(s):  0.3%us,  0.3%sy,  0.0%ni, 99.3%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

Mem:   1017080k total,   590948k used,   426132k free,    61656k buffers

Swap:   212984k total,        0k used,   212984k free,   464256k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND

15949 asterisk -11   0 41260  19m 8712 S  1.7  1.9   2:46.85 asterisk

[Maarten Bezemer]

On Tue, 13 Mar 2012, suboxes wrote:

> The only question I had was is the 500ms delay normal or is it just a
> problem with the E1752C's? Are there any tweaks that can be done to
> limit the delay?

Is that 500ms delay different from the delay when using the same SIM card
in a normal cellphone? Some delay is standard for GSM. Of course there
would be a little extra delay when piping the audio through asterisk, but
that should be negligable compared to normal GSM delay...

--
Maarten

[Alejandro]

i use ubuntu server 10.04.4 (kernel Linux 2.6.32-38-server #83-Ubuntu SMP Wed Jan 4 11:26:59 UTC 2012 x86_64 GNU/Linux

Running Asterisk 1.8.3.3 with chan dongle 1.1 rev 10 with 2 dongles each (i have 2 production servers)

With this software and config, all runs really smooth.

Modems are configured modifying usb_modeswitch to manage huawei strings

I hope this info can be usefull.

I notice you have a high CPU usage under load, asterisk don't uses too much resources, only when managing big queues or when transcoding is enabled. Check your settings.

lsusb of one of my modems (so u can compare)
-----------------------------------------------------------------
Bus 001 Device 016: ID 12d1:1001 Huawei Technologies Co., Ltd. E620 USB Modem
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x12d1 Huawei Technologies Co., Ltd.
  idProduct          0x1001 E620 USB Modem
  bcdDevice            0.00
  iManufacturer           3 HUAWEI Technology
  iProduct                2 HUAWEI Mobile
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          131
    bNumInterfaces          5
    bConfigurationValue     1
    iConfiguration          1 Huawei   Configuration
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           3
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               5
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200  1x 512 bytes
        bInterval              32
----------------------------------------------------------------




El 13/03/12 19:52, Andrew Geddes escribió:

[Andrew Geddes]

Maarten

It is about 250-300ms more than the standard delay than what I am able to measure on a standard cell phone. The delay is still within what is needed for normal conversation and on test calls the other party was not aware of it for the most part. Still very usable and a HUGE improvement over all of the problems that I was having trying to get a working setup with chan_mobile. I could never find a mobile that was reliable and supported voice/sms with CID support on both voice/sms. WIth the testing that I have done thus far it seems quite reliable.

Andrew 

[suboxes]

The setup that I am running my asterisk server on is a pretty low power unit. It is a NeoWare CA22 with a 1 GHz Via Esther CPU. I have gone this route for several reasons: no moving parts, low power consumption, cheap, and x86 CPU architecture.  From what I am aware 1-2% CPU usage per channel doesn't seem too bad. Even when trans-coding from ulaw to g729 it is has only been 3-5% CPU usage per channel. Even trans-coding this server should have more than enough over head to handle the 4-6 concurrent calls that is the max this server will see. My primary asterisk server is hosted on AWS and this server is going to be strictly used to bridge calls and send bulk SMS to mobile carriers in Ecuador where we are setting up a small business. What did you mean by " Modems are configured modifying usb_modeswitch to manage huawei strings "? I have not seen anything referencing that. Would you mind sending me a link?

Thanks,

Andrew

[Alejandro]

I dont know if in the new release of usb_modeswitch this dongles are included in the database.
So, to get them to work, i have to switch them. To do this, you need to modify data files of usbms to manage this model.

I have no time right now, but if you google for info (usb modeswitch huawei) gonna find lot of info.

But, i asume you dont need to do this, if you are able to generate a call, means modem is already switched.

El 14/03/12 00:53, suboxes escribió:

[Franjo Posavec]

I have 

Intel(R) Pentium(R) 4 CPU 2.80GHz

Asterisk 1.8.10.0

E1552 and E1752

and i have also delay of cca 500ms and more.

I have latest chan_dongle revision... 

Any advice?

 

[suboxes]

Franjo,

Up till now I have not been able to reduce the delay but at this point the delay is not long enough to inhibit normal conversation. If somebody has any tips I would love to try them out.

Andrew

[Alejandro]

I have about 8 E1752, with a max delay of 200ms, up and running. But all of them are on new motherboards and in a USB 2.0 hub. Maybe USB chipset is the trouble. That CPU is old, and usb ports in the motherboard are for sure 1.1 version. Try with 2.0 version in a PCI usb board, maybe that solves the issue.

Greets
Alejandro

El 26/03/12 16:54, suboxes escribió:

[Franjo]

I tested now on Intel Atom PC, debian 6, 32bit.
I forgot to mention that I receive call on one dongle and dial on another donge

this is my dial plan:
exten => XXXXXXXXX,1,Noop(Zovemn moby)
    samo => some dialplan functions....
    same => n,dial(dongle/dongle1/XXXXXX)

and delay is about 1sec

on test server I use:
K3520 - receive call
E180 -dial out

Franjo Posavec

skype: franjo.posavec
www.franz-net.info

On 03/27/2012 02:34 AM, Alejandro wrote:

I have about 8 E1752, with a max delay of 200ms, up and running. But all of them are on new motherboards and in a USB 2.0 hub. Maybe USB chipset is the trouble. That CPU is old, and usb ports in the motherboard are for sure 1.1 version. Try with 2.0 version in a PCI usb board, maybe that solves the issue.

Greets
Alejandro

El 26/03/12 16:54, suboxes escribiĂł:

Franjo,

Up till now I have not been able to reduce the delay but at this point the delay is not long enough to inhibit normal conversation. If somebody has any tips I would love to try them out.

Andrew

On Sunday, March 25, 2012 3:08:38 PM UTC-6, Franjo Posavec wrote:

I have 

Intel(R) Pentium(R) 4 CPU 2.80GHz

Asterisk 1.8.10.0

E1552 and E1752

and i have also delay of cca 500ms and more.

I have latest chan_dongle revision... 

Any advice?

 

[bg]

bus 001 is USB 1.1, right ?

also this can be happened when one dongle income call and other
outgoing