Marco,
Interesting case.
If I understand you, the B2BUA is irrelevant to the case. The essence of
it is that a referror wants to tell a referee to only try the referred
call for a certain amount of time before giving up on it.
That does seem to be a case where Expires on INVITE has some utility.
You didn't say, but what I presume you are considering is embedding an
Expires parameter in the Refer-To URI:
Refer-To: sip:[EMAIL PROTECTED]:60
This would then turn into an INVITE w/Expires. For this usage it doesn't
really matter whether it is done by the inviter or by the invitee, as
long as it is done.
So I think this is a good usage, except that you must be concerned if
the referee will honor the embedded Expires header and put it into the
INVITE, and whether at least one of the referee and invitee act on it to
terminate the INVITE. These aren't sure things.
Thanks,
Paul
Marco Ambu wrote:
> Paul Kyzivat ha scritto:
>> 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.
> Me too, I found this "feature" investigating how to implement another
> feature in our B2BUA. Probably it is better to directly explain what my
> problem is.
>
> A calls B through a B2B. A transfers B to C. C rings but never answers.
> After some times A sees that the transfer is not already performed
> (NOTIFY terminated not yet received) and wants to terminate the transfer
> (that is say to B to give up calling C) so that A can resume his call
> with B.
> One solution can be to put some "transfer-expire-time" parameter in our
> B2B that makes the B2B send a cancel in the new leg with C if C doesn't
> answer before that time. Of course the parameter is the same for every
> call and A cannot control this behaviour.
> Maybe there is another common solution.
>
> Thanks.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
