You're right that you need to increase your inactivity timeout. But when you are using reliable sessions, the receiveTimeout is also taken into account. From this MSDN Article:
When using a reliable session, there are two different inactivity
timers that must be satisfied to keep the connection alive. If either
of these inactivity timers goes off, then the connection is dropped.
The first inactivity timer is on the reliable session and is called
the InactivityTimeout. This inactivity timer fires if no messages,
either application or infrastructure, are received within the timeout
period. An infrastructure message is a message that is generated for
the purpose of one of the protocols in the channel stack, such as a
keep alive or an acknowledgment, rather than containing application
data.
The second inactivity timer is on the service and uses the
ReceiveTimeout setting of the binding. This inactivity timer fires if
no application messages are received within the timeout period. This
specifies, for example, the maximum time a client may take to send at
least one message to the server before the server will close the
channel used by a session. This behavior ensures that clients cannot
hold on to server resources for arbitrary long periods.
Since the connection is dropped if either inactivity timer fires,
increasing InactivityTimeout once it is greater than ReceiveTimeout
has no effect. The default for both of these timeouts is 10 minutes,
so you always have to increase both of them to make a difference when
using a reliable session.
Setting both of these values to "Infinite" (if you're using config files) or TimeSpan.MaxValue
if you're setting your bindings up in code should achieve what you're looking for.
EDIT 1
Setting the receiveTimeout and inactivityTimeout values to "infinite" will generate a warning in the compiler. This is okay. The IDE uses an XSL that doesn't take that keyword into account. Behind the scenes, WCF is using a TimeSpanOrInfiniteConverter to convert the keyword to TimeSpan.MaxValue. Source