G729 questions

Discussion in '3CX Phone System - General' started by itgs, Apr 25, 2009.

Thread Status:
Not open for further replies.
  1. itgs

    Joined:
    Nov 8, 2008
    Messages:
    57
    Likes Received:
    1
    Scenario:

    3cx hosted on a dedicated server with public ip address on the eth interface (no nat) and mini-edition license activated.
    1 Provider configured ONLY with G729 codec enabled.
    1 remote extension with G729 on-board licensed (Linksys SPA941) and configured to use ONLY the G729 codec.
    1 Incoming route to forward the call to remote extensions and after 5 seconds forward to voice mail.
    The option : "PBX Delivery audio" not enabled on the 3cx and on the extension.

    Checking with performance monitor the G729 usage counter, I noticed a strange thing:

    During the ringing the G729 licenses increase to 4 !!
    Yes... you understand right: four licenses for one incoming call.... :shock:

    When call is forwarded to voice mail, the G729 licenses usage decrease to 0.

    In both case (ringing and voice mail transfer) , the "Calls bound to mediaserver" value was = 0

    So, I made some investigation and ask to my voip provider to send me the log of the session.

    This is the part of SIP messages related to media rtp negotiation during the INVITE step:

    m=audio 7120 RTP/AVP 18 18 18 18 8 0 4 96 97 2 98 3 99
    a=rtpmap:18 G729A/8000
    a=ptime:40
    a=rtpmap:18 G729B/8000
    a=ptime:40
    a=rtpmap:18 G729AB/8000
    a=ptime:40
    a=rtpmap:18 G729/8000
    a=ptime:40

    a=rtpmap:8 PCMA/8000
    a=ptime:40
    a=rtpmap:0 PCMU/8000
    a=ptime:40
    a=rtpmap:4 G723/8000
    a=ptime:30
    a=rtpmap:96 G726-16/8000
    a=ptime:40
    a=rtpmap:97 G726-24/8000
    a=ptime:40
    a=rtpmap:2 G726-32/8000
    a=ptime:40
    a=rtpmap:98 G726-40/8000
    a=ptime:40
    a=rtpmap:3 GSM/8000
    a=ptime:40

    How you could verify checking the red lines highlighted, the provider send four types of G729 codec availabilty.

    This is log section when 3cx accept the incoming communication (OK message):

    m=audio 9004 RTP/AVP 18 18 18 18 99
    c=IN IP4 80.80.80.80
    a=rtpmap:18 G729/8000
    a=rtpmap:18 G729/8000
    a=rtpmap:18 G729/8000
    a=rtpmap:18 G729/8000

    a=rtpmap:99 telephone-event/8000
    a=sendrecv

    In this case, you can see that 3cx accept 4 times the same codec, using in one shot all the g729 licenses.
    And this is not good...... !

    I hope that some 3cx guy, could read my post to fix this issue.

    Thanks to everyone
     
  2. alexmallia

    alexmallia New Member
    3CX Support

    Joined:
    Aug 4, 2008
    Messages:
    130
    Likes Received:
    0
    Hi

    We are looking into this. Can you tell us what voip provider are you using?

    regards
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. itgs

    Joined:
    Nov 8, 2008
    Messages:
    57
    Likes Received:
    1
    Hi Alexmallia and thank you for interesting.

    The provider is an Italian Regional provider: Uno Communications (http://www.uno.it).
    I don't think you already knew it.

    I have a privileged rapport with the tech support.
    If there is other informations that I can supply, just ask me.

    Thank you for support.
     
  4. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    I can understand the idea of such kind of SDP which is sent by your VoIP provider. but...

    In my humble opinion :) , this part of SDP:
    breaks at least 4 rules related to RFCs (4566, 4856).
    I suspect the miscofiguration of hardware/software on VoIP provider side.
    I may be wrong, so everybody can refute my opinion.

    Thanks

    P.S. I'm glad to know the source of "4 licenses per one call" issue
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  5. itgs

    Joined:
    Nov 8, 2008
    Messages:
    57
    Likes Received:
    1
    Thank you SY for your opinion.

    I'm not a Voip specialist, and I would be very grateful if you can point out exactly in wich point of the RFC the rules are breaked, because my provider tell me that the problem is in 3CX and suggest me to study the rcf. :x

    Best regards
     
  6. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    Ok. Did they specify the RFC you need to study? We can study those RFCs together.

    Thanks

    P.S. There are a lot of subjects to discuss :)
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  7. itgs

    Joined:
    Nov 8, 2008
    Messages:
    57
    Likes Received:
    1
    They don't tell me nothing. It was a bad way to close the discussion with me.

    If I will ask them wich rfc they refeer, I'm sure that this issue risk to became a flame between us.
    I can't do this because I have several lines on this provider and I don't want compromise my situation.

    This is the reason why I would like to identify in rfc the section where is described the correct procedure to negotiate codecs and force them to provide me explanation.

    Maybe they can tell me that I'm ignorant, maybe could tell you the same ... but I'm not sure that they can dispute the IETF !
    ;-)

    Thank you
     
  8. SY

    SY Well-Known Member
    3CX Support

    Joined:
    Jan 26, 2007
    Messages:
    1,825
    Likes Received:
    2
    IETF is not a subject for discussion :)
    The problem is that I, personally, cannot find any rules how to interpret text which is the SDP offered by your VoIP provider. Do they have any useful hints?
    We will support your VoIP provider immediately after this information will be received!

    Thanks
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  9. itgs

    Joined:
    Nov 8, 2008
    Messages:
    57
    Likes Received:
    1
    Could you write me exactly the questions I need to forward to my provider or... better... could you contact directly them so you can talk in your "SIP language" that I don't understand ?

    If this could be useful, I want you know that I'm a VAR for this providers and many of my customers utilize their voip accounts.

    If I solve this issue, is in my projects, provide voip services to my customers moving their accounts under 3CX and this is (in marketing language that I understand better!) more G729 licenses selling. ;-)

    Thank you for your needful support.
     
  10. itgs

    Joined:
    Nov 8, 2008
    Messages:
    57
    Likes Received:
    1
    Hi SY !

    I talk with provider and tell me that are available to solve this issue together.

    Let me know if I can communicate you their contact.

    Thank you
     
  11. itgs

    Joined:
    Nov 8, 2008
    Messages:
    57
    Likes Received:
    1
    Hallo... is there anybody out there ???
    :)
     
  12. Nick Galea

    Nick Galea Site Admin

    Joined:
    Jun 6, 2006
    Messages:
    1,926
    Likes Received:
    243
    Unfortunately we are not able to go into that detail. Its best you use a supported voip provider.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  13. itgs

    Joined:
    Nov 8, 2008
    Messages:
    57
    Likes Received:
    1
    This is a "not answer." :-(

    Why SY told me this: "We will support your VoIP provider immediately after this information will be received!" ?

    My provider give me total availabilty to provide more informations.

    What's the problem ? I need to pay for support ?

    Thank you
     
  14. Nick Galea

    Nick Galea Site Admin

    Joined:
    Jun 6, 2006
    Messages:
    1,926
    Likes Received:
    243
    Troubleshooting a VoIP provider is very time intensive and can not be done as part of standard support. Yes, to get support you need to get a support package and also to use a supported voip provider.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
Thread Status:
Not open for further replies.