Andreas,

Could you provide a tcpdump trace with your call scenario to support@ag-projects.com? We have no device with which to replicate the problem ourselves and I think is a valid call flow you describe.

Regards, Adrian

========

Hi,

I've tried mediaproxy and it works for "normal" audio streams, but doesn't work for T.38 reINVITES with different RTP ports. Can anyone confirm this or does anyone have a solution?

Scenario:

A sends INVITE to SER with SDP audio, port=5004 SER sends INVITE to B with SDP audio, port=35004 (mediaproxy port) B sends OK to SER with SDP audio, port=5004 SER sends OK to B with SDP audio, port=35004

Now G.729 audio is proxied via mediaproxy correctly, until:

A sends reINVITE to SER with SDP image, port=6004 SER sends reINVITE to B with SDP image, port=35004 B sends OK to SER with SDP image, port=6004 SER sends OK to B with SDP image, port=35004

A and B now send T.38-packets to mediaproxy, which doesn't forward them to the endpoints (neither to port 6004 nor to 5004). There is also only one session shown with session.py (I guess the G.729-session on ports 5004-5004). It seems that mediaproxy doesn't open a new pair of ports for this reinvite.

It then works again with G.729-audio after the fallback:

A sends reINVITE to SER with SDP audio, port=5004 SER sends reINVITE to B with SDP audio, port=35004 B sends OK to SER with SDP audio, port=5004 SER sends OK to B with SDP audio, port=35004

It's not possible to configure the UACs to use the same port for G.729 and T.38 (Mediatrix 2102) for a workaround.

Andy