I agree with Brett and Dale.
Transactions exist at a logically lower layer than dialogs. Changing
state of the dialog does not affect any transaction. Each transaction
must follow its state machine independently.
Regarding how long to allow ringing ringing to continue: IMO this needs
to be closely coupled to the application/UI. The UAS should make its own
decision, and perhaps have a policy to reject the call if its alerting
doesn't result in an answer in some reasonable time. The UAC side may
want to keep the call up as long as the callee is willing and its own
user hasn't hung up. But if there is a chance that the UAC is unattended
it might want to give up eventually. (There is a tradeoff here with
disappointing a user that *wants* the call to continue ringing.)
Thanks,
Paul
On 3/20/12 1:59 PM, Worley, Dale R (Dale) wrote:
>> From: M. Ranganathan [[email protected]]
>>
>> Consider the following two scenarios:
>>
>> Scenario 1
>> =========
>> Invite Client Transaction sent by UAc creates a Dialog.
>> - Sends INVITE
>> - Server side sends RINGING periodically once every 30 seconds for ever.
>>
>> Dialog remains in early state for 3 minutes and times out.
>>
>> What happens to the INVITE Client Transaction ? Should the SIP stack
>> automatically terminate it?
>>
>> Scenario 2
>> =========
>> Invite Server transaction gets INIVTE.
>> Application creates a dialog.
>> Application keeps sending 180 periodically once every 30 seconds for ever.
>> Server Dialog times out after 3 minutes in early state.
>> What should the SIP stack do with the invite Server Transaction?
>> Should it be automatically deleted after the Dialog times out?
>
> I'm not sure, but I think you believe that the transaction is required
> to time out after 3 minutes. That is not true. Searching for "3
> minute" in RFC 3261 turns up a few uses, whose import is that the UAC
> times out its request if more than 3 minutes elapse between responses
> that it receives. Within RFC 3261, if the UAS sends 180 every 30
> seconds forever, the UAC is not required to terminate the transaction.
>
> Now, if the UAC's Timer C expires because it doesn't receive responses
> for long enough, the UAC should terminate the transaction. As Brett
> noted, the UAC can send BYE on the early dialog to terminate just that
> early dialog, or it can send CANCEL to cancel that fork of the INVITE,
> or all forks of the INVITE. But RFC 3261 only requires that Timer C
> be *at least* 3 minutes.
>
> For humanity's sake, a UAC should terminate a ringing dialog after
> some long period of time, and send a 4xx response. But RFC 3261 does
> not require that.
>
> Dale
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
