Invite client transaction
(Has got no responses yet)
User Cancels
RFC 3261 says:
If no provisional response has been received, the CANCEL request MUST
NOT be sent; rather,
the client MUST wait for the arrival of a provisional response before
sending the request.
Now cancel is queued by transaction.
Transaction gets for example 180 ringing, goes proceeding state
Transaction completes queued cancel
(Normally we must get 478 Request terminated)
If we don't get it, what times out transaction ? If i look Invlite
client transaction
drawing(17.1.1.2), i don't see any timeout timer fot Proceeding state.
Seems i missing something ...
Timer B controls calling state timeout only or there is only 1 case,
whats not in rfc, if
transaction wont switch to proceeding state, timer B will time out.
Some simple things are so complicated sometimes ... .
[EMAIL PROTECTED] wrote:
>
> Please see comments inline.
>
> Regards,
> Ramakrishna
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Ivar
> Sent: Tuesday, April 10, 2007 11:06 PM
> To: [EMAIL PROTECTED]
> Cc: [email protected]
> Subject: Re: [Sip-implementors] Cancel and server transaction
>
>
> Hi,
>
>
>> All server transactions linger for the 3 minutes
>>
> Hmm can you point me such place in rfc ?
> If i look rfc 3261 17.2.x
> Server transactions will destroy too if final response, only in some
> cases linger for 4 seconds.
> Also what the use of Cancel then if transaction linger so long time.
> And also normally retransmit of request ot server transaction won't
> happen, because server transaction must send 100 trying (i mean at least
> time you in real life cancel transaction).
> The only idea is to cancel Invite when ringing. And i suspect Cancel
> will terminate transaction or there is no meaning/use of cancel.
>
> <comment>
> Invite server transaction cannot terminate immediately as it has to wait
> for the ACK. Both Client and Server transactions linger to take care of
> the issues with non-reliability of the transport, if you see, Timers D,
> K, I and J are set to zero for reliable transports.
> </comment>
>
>
> [EMAIL PROTECTED] wrote:
>
>> From: Ivar <[EMAIL PROTECTED]>
>>
>> But what happens to server transaction after cancel ?
>> Logical is that it will be terminated and disposed (because nothing
>>
> to
>
>> do with that server transaction), but can't see place what
>>
> describes it.
>
> <comment>
> Section 9.2: If the original request was an INVITE, the UAS SHOULD
> immediately respond to the INVITE with a 487 (Request Terminated).
>
> Section 17.2.1: While in the "Proceeding" state, if the TU passes a
> response with status code from 300 to 699 to the server transaction, the
> response MUST be passed to the transport layer for transmission, and the
> state machine MUST enter the "Completed" state.
> </comment>
>
>
>> Client transaction can't dispose at once, thats clear, because
>>
> invite
>
>> transaction should get 487 'Request Terminated'.
>> There I'm thinking about linger terminate 5 sec for 478 to
>>
> arrive.
>
>> All server transactions linger for the 3 minutes (or whatever it says
>> in 3261), so that if a re-transmission of the request is received, the
>> server can re-send the response.
>>
>> The client INVITE transaction can be terminated immediately once a
>> final response is received. (Which might not be 487, due to race
>> conditions, and may even be a success response.)
>>
>> Similarly for the client CANCEL transaction.
>>
>> 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
>
>
> The information contained in this electronic message and any attachments to
> this message are intended for the exclusive use of the addressee(s) and may
> contain proprietary, confidential or privileged information. If you are not
> the intended recipient, you should not disseminate, distribute or copy this
> e-mail. Please notify the sender immediately and destroy all copies of this
> message and any attachments.
>
> WARNING: Computer viruses can be transmitted via email. The recipient should
> check this email and any attachments for the presence of viruses. The company
> accepts no liability for any damage caused by any virus transmitted by this
> email.
>
> www.wipro.com
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
