Problem with g729 call - cant get around it

[h2009]

Hi there,
Ok im still having the problems with the G729 codec calls. It seems 3CX is dropping the call before RTP are sent/received. I've tested my firewall, its all open, all working fine. Any other codec works fine. My SMB licence is active and has 4 G729 lines. I've been in contact with Mondotalk (SIP) and there end is fine. The way 3CX picks the packets up is causing the problem which i can't fix.
I've been trying for about a week now with no luck. Any help would be greatful.

Here is the log from the server:

21:29:53.588 MediaServerReporting::RTPReceiver [MS105000] C:29.2: No RTP packets were received:remoteAddr=212.248.194.5:39798,extAddr=82.24.13.76:9012,localAddr=82.24.13.76:9012
21:29:53.370 MediaServerReporting::RTPReceiver [MS105000] C:29.1: No RTP packets were received:remoteAddr=192.168.0.198:16458,extAddr=82.24.13.76:9010,localAddr=82.24.13.76:9010
21:29:53.370 Call::Terminate [CM503008]: Call(29): Call is terminated
21:29:53.338 Call::Terminate [CM503008]: Call(29): Call is terminated
21:29:53.213 CallCtrl:nLegConnected [CM503007]: Call(29): Device joined: sip:[email protected]:5060
21:29:53.213 CallCtrl:nLegConnected [CM503007]: Call(29): Device joined: sip:[email protected]:5060
21:29:53.041 Line:rintEndpointInfo [CM505003]: Provider:[Mondotalk] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [CityMoon SIP/1.8.0.004] Transport: [sip:192.168.0.200:5060]
21:29:53.041 CallCtrl:nAnsweredCall [CM503002]: Call(29): Alerting sip:[email protected]:5060
21:29:52.104 CallCtrl:nSelectRouteReq [CM503004]: Call(29): Calling: VoIPline:10@[Dev:sip:[email protected]:5060]
21:29:52.104 CallCtrl:nSelectRouteReq [CM503010]: Making route(s) to [sip:[email protected]]
21:29:52.088 Extension:rintEndpointInfo [CM505001]: Ext.117: Device info: Device Identified: [Man: Linksys;Mod: SPA-921;Rev: General] Capabilities:[reinvite, no-replaces, able-no-sdp, recvonly] UserAgent: [Linksys/SPA921-5.1.8] Transport: [sip:192.168.0.200:5060]
21:29:52.088 CallCtrl:nIncomingCall [CM503001]: Call(29): Incoming call from Ext.117 to [sip:[email protected]


Here is wireshark capture
codec problem UDP.zip - is a small capture of the problem

I'd be so greatful if someone could solve my problem

Thanks.

 

[h2009]

Anyone?
I've been told by my sip providers to have the guys at 3CX to look at my wireshark report.

 

[N_G]

We are quite sure that G729 works fine. However you are using an unsupported provider. Please try with a supported VOIP provider.

 

[h2009]

Hi there,
Its the same issue. From two other 'supported' providers.

The call is terminated, before the RTP packets were sent/received.

Could you have a look at the wireshark logs please - the details are on number 17-21.

The 3CX is a demilitarized zone, so the firewall isnt the issue?

 

[archie]

Your provider supports only G729, so either you have free version, or you had another calls on g729 at the time so you didn't have free g729 channels at the time.

 

[h2009]

Mondotalk support both codec g711u/a and g729 - im using g711 now because g729 isnt working.
The license isn't the issue - i got the SMB license from yourselves, so unless thats not work (which i doubt because its registers fine and displays 4 lines for g729.
There are no other providers which using the g729 lines, which is what strange.

Any other ideas?

 

[archie]

Erm, please check if you have g729.dll in ...\3CX PhoneSystem\Bin\Codec folder.
What version do you use, btw?

 

[h2009]

Yes i have that file.
Its the latest version (completely up to date), with all the little patchs as well.

I've tried reinstalled and fresh settings but its the same issue.

What i dont understand is this part of the log:
21:29:53.588 MediaServerReporting::RTPReceiver [MS105000] C:29.2: No RTP packets were received:remoteAddr=212.248.194.5:39798,extAddr=82.24.13.76:9012,localAddr=82.24.13.76:9012
21:29:53.370 MediaServerReporting::RTPReceiver [MS105000] C:29.1: No RTP packets were received:remoteAddr=192.168.0.198:16458,extAddr=82.24.13.76:9010,localAddr=82.24.13.76:9010
21:29:53.370 Call::Terminate [CM503008]: Call(29): Call is terminated
21:29:53.338 Call::Terminate [CM503008]: Call(29): Call is terminated

Why is the call terminating before the RTP packets report back?
Oh calling for snom 300/320/360 and linksys spa921. All calls always end up like this when g729 is the only codec used.

I've also been speaking to mondotalk and their voicemail line only accepts g729 codec, before i activate the SMB license the line was completely dead. Now after activating it, i can hear the voicemail line but looking at the linksys phone status page is says its communicating in g711 codec.
Not sure if that helps you or not, but i thought i'd add it.

 

[SY]

We are supporting only G.729A
G.729B is not supported

Thanks

 

[h2009]

Mondotalk are only using g729a.
It connects fine when calling direct. i.e. phone to SIP.

Somethings not quite right, and its to do with 3CX, as i've changed everything else in between.
Shall i said you my license code so you can check it over?

 

[archie]

From your logs: INVITE on line 17 has SDP with
a=fmtp:18 annexb=yes

which exactly means G729B which we're not supporting.
There was no other codecs offered, so the call was dropped even before RTP is sent (No common codecs failure)

 

[SY]

Mondotalk are only using g729a.
It connects fine when calling direct. i.e. phone to SIP.

Somethings not quite right, and its to do with 3CX, as i've changed everything else in between.
Shall i said you my license code so you can check it over?

Hi
I believe, they are using G729a

From your capture:
v=0
o=root 1206963284 1206963284 IN IP4 _____________
s=Koncept Session
c=IN IP4 _____________
t=0 0
m=audio 64708 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=alt:1 2 : BHEzdZbE emYE7jtn 192.168.1.4 44232
a=alt:2 1 : yj1RGGoD sVFzLSOc 124.169.179.145 50285
a=sendrecv


Thanks for your comments

 

[h2009]

so where does that leave my problem? Any idea my fellow voip members.

 

[archie]

Try to convince your provider to use G.729A

 

[h2009]

Are you sure its them? Because my linksys phone only supports g729a, and that work fine when directly connected to them.

Oh and on a side note, is there any reason why g729 is in the 3CX codec list and not g729a & g729b?

I've emailed mondotalk just waiting for there reply.

 

[h2009]

Ok i've checked with Mondotalk and they are ONLY using g729a - and not G729b.

Could it be a header communications problem between 3CX and mondotalk.

 

[h2009]

Ok i've made another two wireshark logs.
Mondotalk servers (for voicemail only) - force only g729a.

The one labled voicemail - call = linksys phone set to any codec, resulting in a working call.
The one labled voicemail - g729 on phone = linksys phone set to force g729, resulting in a hanging up of call.


The wireshark files have beeen zipped (upload rules of the forum). There is two files contained within the zip file.

Thanks for your help.

 

[archie]

Ok i've made another two wireshark logs.

Now you have different problem. SDP from roedean.ath.cx:

Request-Line: INVITE sip:[email protected] SIP/2.0
Message Header
Message body
Session Description Protocol
Session Description Protocol Version (v): 0
Owner/Creator, Session Id (o): - 78751439 78751439 IN IP4 xxxxx
Session Name (s): -
Connection Information (c): IN IP4 xxxx
Time Description, active time (t): 0 0
Media Description, name and address (m): audio 16430 RTP/AVP 18 101
Media Attribute (a): rtpmap:18 G729a/8000
Media Attribute (a): rtpmap:101 telephone-event/8000
Media Attribute (a): fmtp:101 0-15
Media Attribute (a): ptime:20
Media Attribute (a): sendrecv

This little 'a' (underscored) is the source of the problem, because it doesn't comply to standard. There's NO G729a type registered by IANA. Only G729, G729d and G729e.

 

[h2009]

Hmm ok,
So does that mean its a header problem?
How would i go about converting all of those g729a's to g729's?

Is this possible to fix/change?

 

[archie]

We're currently considering a patch for that problem. You can not fix it yourself unless you can filter and patch your SIP traffic to PBX.