shweta kavishwar wrote:
> Hi,
> Please verify if this understanding is correct.
>
> Consider the following scenario:
> UAC supports session-timer extension & UAS dosent.
> UAC sends an INVITE request with Session-Expires header & Supported:timer.
>
> UAS behavior:
> - It either blindly copies the session-expires header in the 2xx response
> with refresher as UAC. (OR)
This is bad behavior on the part of the UAS. It should never be blindly
copying headers it doesn't understand from the request to the response.
> - There might be no Supported/Session-Expires headers in the response.
For a UAS that doesn't support timer this is valid and expected behavior.
> For the above scenarios, what should be the correct UAC behavior?
> - On receiving the 2XX response with session-expires header with refresher
> parameter as UAC, it starts the
> session timer & performs subsequent refreshes. (OR)
In the first (invalid) case, the UAC can't tell that anything is wrong.
So presumably it would start performing refreshes.
> - It does not start any session timer.
In the latter case this is what would be expected.
> Again, if the UAS sends a malformed 2XX response i.e. no supported:timer
> tag, Session-Expires with refresher
> as 'uas', how should the UAC process this response?
> Does it start the session timer and terminate the session with BYE after
> timer expiry when no refresh request
> comes from the UAS end?
Your call.
All the above is predicated on the UAC putting Session-Expires with
refresher=uac in the request.
Why would you do this? What possible value is achieved? The UAC can test
the connection any time it wants via a reINVITE without establishing a
session timer. The value in session timer is when it is requested by a
proxy, who can't test the connection on its own.
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
