Cool guy u r doing great.. 
                      
           A statefull proxy will have timer in it and it called timerc
and when statfull proxy forwards any INVITE request it starts its TIMERC
and wait for response..and ..if it did not get response.in time.as in
TIMERC, it will retransmit the..request..and remember..that for that
INVITE request if get 100 trying then it never retransmit the
reqest..and statefull proxy wait for 3min to get response after..it will
simply discard the transaction..
1.A stateless proxy never retransmit the request ..
 2.Default value for proxy server timer is 500ms or 4 sec..
  3.A statefull proxy must store a forwarded request or generated
response messages for 32 sec for matching the futher request and
response to the current one. 
 
Regards,
Chandra Sekhar Murthy M.v.v
[EMAIL PROTECTED]
 
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ivar
Sent: Wednesday, April 11, 2007 1:53 PM
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: [Sip-implementors] Cancel and server transaction


Hmm, For invite server transaction i missed 487 ACK wait, and for other 
method cncel has no effect.
Yep ACK timers will tke care of disposing INVITE transaction.

thanks, i must think a little ... .

[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



_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to