Hi Geetha
I think starting timer B when INVITE request is proxied doesnt make sense as
timer C is always started. But you may have to confirm this.
Timer C is restarted on receiving any provisional responses. Extract from
3261 -
As client transactions pass responses to the proxy layer, the
following processing MUST take place:
2. Update timer C for provisional responses
On 9/13/06, karthik <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I have a basic doubt regarding Timer C.
>
> Section 16.6 bullet 11
>
> "In order to handle the case where an INVITE request never
> generates a
> final response, the TU uses a timer which is called timer C. Timer C
> MUST be set for each client transaction when an INVITE request is
> proxied.
> The timer MUST be larger than 3 minutes. Section 16.7 bullet 2
> discusses how this timer is updated with provisional responses,
> and
> Section 16.8 discusses processing when it fires."
>
> From this it is clear that Timer C should be started when request
> is
> proxied.
>
> My question here is what is the use of Timer B in Transaction
> Stateful
> Proxies.
> From my understanding once Timer B fires the transaction layer
> would
> destroy the
> client transaction.
>
> Starting the Timer C after receiving the first 1xx response and
> refreshing it on subsequent
> provisional responses sounds fine. This is the behaviour given in
> bis-05. Why has this
> been changed in bis-09.
>
>
> Thanks and Regards,
> Geetha.
> --
> karthik
> [EMAIL PROTECTED]
>
> --
> http://www.fastmail.fm - Or how I learned to stop worrying and
> love email again
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
--
With Regards
Retesh Chadha
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
