Thanks, proxy and "proxy context" part i think i did as needed (At least 
now no questions).
(Just implemented sequential/parallel forking and Request-Disposition 
header directive support for proxy)

Server transaction cancel is ok now too, must look client transaction over.

The c# code is available for everyone:
http://www.lumisoft.ee/lswww/download/downloads/Net/

To sad is that there is so slow interest on c# SIP solutions ... .

Chandra Sekhar Murthy M.V.V. wrote:
> 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