Marco,
I've wondered about this too.
Obviously the UAC is free to send a CANCEL at any time, whether it
included an Expires in the INVITE or not. So the value of this header
has to be in what effect it has on the UAS. If the UAS does as
specified, then there is indeed no reason for the UAC to send a CANCEL.
So, the purpose of the CANCEL must be to cover the case where the UAS
fails to abort the request on its own. But since the UAS *knows* the UAC
will send a CANCEL if it really cares, then there is even less incentive
for the UAS to handle this case.
That means that the only real advantage to the UAS of doing this is so
that it can stop the call slightly sooner - by the amount of time it
takes for the CANCEL to be generated, get to the UAS, and be processed.
Since it can be presumed that the CANCEL will be coming in that case,
stopping sooner avoids the risk of the call being answered in the
interim, and then being hung up on. But this is a really marginal benefit.
Bottom line: I can see very little value in this feature.
Paul
Marco Ambu wrote:
> Hi,
> it is clear what to do when initiating a session using an INVITE with Expires
> header... but some questions remain (at the end of this mail).
>
> [from RFC 3261]
> 13.2 UAC Processing
> 13.2.1 Creating the Initial INVITE
> [...]
> The UAC MAY add an Expires header field (Section 20.19) to limit the
> validity of the invitation. If the time indicated in the Expires
> header field is reached and no final answer for the INVITE has been
> received, the UAC core SHOULD generate a CANCEL request for the
> INVITE, as per Section 9.
>
> 13.3 UAS Processing
> 13.3.1 Processing of the INVITE
> [...]
> 1. If the request is an INVITE that contains an Expires header
> field, the UAS core sets a timer for the number of seconds
> indicated in the header field value. When the timer fires, the
> invitation is considered to be expired. If the invitation
> expires before the UAS has generated a final response, a 487
> (Request Terminated) response SHOULD be generated.
>
>
> This means:
> UAC-------------->UAS
> INVITE B
> Expires: 30
>
> UAC<--------------UAS
> 100
>
> after 30 seconds
>
> UAC-------------->UAS
> CANCEL
> [200 CANCEL, 487 INVITE, ACK]
>
> so probably at UAS side, the timer never fires because UAC sets his timer
> when sending and UAS when receiving.
>
> Why both UAC and UAS have to set the timer to take future actions?
> Wouldn't be better if only B set the timer so that no CANCEL is needed?
>
> Thanks.
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
