[Home]

Summary:ASTERISK-17273: [patch] - Incorrect address specified in SIP re-INVITE with T.38 when directmedia enabled
Reporter:dario (dario)Labels:
Date Opened:2011-01-23 06:59:54.000-0600Date Closed:2013-09-23 13:37:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:Frequency of
Occurrence
Related
Issues:
is duplicated byASTERISK-18706 UDPTL fail while using directmedia
is related toASTERISK-18706 UDPTL fail while using directmedia
Environment:Attachments:( 0) chan_sip.c.patch
( 1) sip.conf
( 2) t38_never_direct.diff
( 3) t38_reinvite_problem.txt
Description:T.38 reinvite doesn't work when directmedia is enabled. VoIP Gateway initiates t.38 reinvnite with ip a.b.c.d and port x, but asterisk forwards this invite to other Gateway with ip a.b.c.d and port y in SDP.
Comments:By: dario (dario) 2011-01-23 13:58:46.000-0600

My sip.conf is in attachment. I use directmedia and directrtpsetup

By: dario (dario) 2011-02-08 15:23:14.000-0600

I checked asterisk with:
directmedia=yes
directrtpsetup=no

T.38 reinvite doesn't work too. There is the same problem with udp ports. Asterisk replace UDP port in invite messages.


T.38 works only with:
directmedia=no

We can use only Packet2Packet bridging mode



By: Kai Hoerner (kaii) 2011-10-18 01:55:18.532-0500

dario, please update this issue and mention which version of asterisk you use.

By: dario (dario) 2011-10-18 04:11:31.368-0500

I use  1.6.2.16.1. I don't know how to update Version/s. On https://issues.asterisk.org/view.php?id=18663 is correct information.

By: Kevin Stewart (skavin) 2013-06-10 23:41:28.831-0500

I have the same problem in 1.8.20.1 here is a quick fix for it.

By: Jonathan Rose (jrose) 2013-09-09 17:00:12.258-0500

Hey Kevin, would you mind explaining some details about your patch?  I understand making the address copying and port setting portions only execute when directmedia isn't in use, but I'm not sure why the portions changing the bit max bitrate and max datagram when using directmedia are needed.

By: Kevin Stewart (skavin) 2013-09-09 21:22:41.317-0500

The changes that are made are to move the doing_directmedia check outside the add_audio block so it can be used when we are renegotiating to T38 and doing direct media.

All my other changes do is copy information from the incoming SDP to the outgoing SDP if we are doing Direct media so the 2 end points can negotiate injecting our t38 config into the SDP would be bad.

If we are doing direct media append m=image with the port received.
If we are doing direct media append T38MaxBitRate received from incoming SDP else use our settings.
If we are doing direct media append T38FaxMaxDatagram received from incoming SDP else use our settings.

Also when parsing SDP ASSUME that their_parms.rate defaults to 14400 if not passed (cisco PGW does not pass any params :/ ) else we will pass this as 0 this would also be bad.

By: Jonathan Rose (jrose) 2013-09-11 18:12:11.634-0500

I've been talking with Mark Michelson about this one a good bit, and the general consensus seems to be that directmedia really just shouldn't be used for a T.38 session at all. I've got a patch in place that should address that, and I've written something resembling a test for it that still needs some work... but basically I'd just like you to see if it works in a real fax scenario.

By: Jonathan Rose (jrose) 2013-09-20 16:30:53.446-0500

Fortunately Jeremy Kister was able to confirm that it worked for him in ASTERISK-18706, so I feel safer about assuming it works here too. I've already committed the patch and will close the issue as soon as a test I wrote for this is approved and added to our testsuite.

By: Kevin Stewart (skavin) 2013-09-22 18:05:05.475-0500

Jonathan Sorry for the long delay I have been on holiday.
I use direct media working for my voice connection.
Why do you think that asterisk is needed in a T38 path if all other calls are working with it not in path?

By: Walter Doekes (wdoekes) 2013-09-23 02:10:42.513-0500

http://lists.digium.com/pipermail/asterisk-dev/2013-September/062679.html