Question: I want to set a session timeout of 30 seconds.

To do so I wrote:

```
<wsHttpBinding>
    <binding name="ServicesBindings">
      <security mode="Message">
        <message clientCredentialType="Certificate"/>
      </security>
      <reliableSession enabled="true" inactivityTimeout="00:00:30"/>
    </binding>
  </wsHttpBinding>

```

But it don't work!

If I set in this way:

```
<wsHttpBinding>
    <binding name="ServicesBindings" receiveTimeout="00:00:30">
      <security mode="Message">
        <message clientCredentialType="Certificate"/>
      </security>
      <reliableSession enabled="true"/>
    </binding>
  </wsHttpBinding>

```

it's all correct.

Can someone explain this to me?

Thanks,

Alberto

Answer: 
InactivityTimeout is for the ReliableSession. It's the amount of time the channel will stay open while no application messages are being sent on the wire. So, if you have a client to call an operation, then sleep for a while, inactivity timeout will fault the client channel if the client doesn't send another message to the service within the configured timeout.
ReceiveTimeout is how long an individual Receive operation can take. For example, the client sends a message to the service. If the service takes longer than ReceiveTimeout to finish reading that message, it will fault.
Likewise, SendTimeout is a timeout for how long a single Send operation can take.

To put it simply - (Send/Receive)Timeout controls how long sending and receiving messages are allowed to take. InactivityTimeout is a setting for the session and has to do with how long you allow nothing to happen.

If you turn on Fiddler and watch the messages on the wire, you'll see that with a large InactivityTimeout and a long enough idle time between sending messages, there will be "Keep Alive" messages sent by the underlying ReliableSessionBindingElement to keep the channel alive despite no communication going on from the application layer.
According to [this person](http://solatys.com/files/technotes/WCF%20Alive%20session.pdf), there is a bug where the receiveTimeout overrides the inactivityTimeout.