[Serusers] reINVITE with port-change via mediaproxy

[Adrian Georgescu]

Andreas,

Could you provide a tcpdump trace with your call scenario to 
support at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 1673 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20041020/27e5e8c6/attachment.bin>