See below.
Thanks, Neel > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip-implementors- > [EMAIL PROTECTED] On Behalf Of venkatesh chandran > Sent: Monday, April 23, 2007 7:14 AM > To: [EMAIL PROTECTED] > Cc: [email protected] > Subject: Re: [Sip-implementors] Regarding SESSION-TIMER > > Hello Neel, > For the query2(what is the real use behind the 422 response?) as you > specified i proposed an optimisation. > But it is not violated RFC 4028.In the section-8.1, it is specified that > proxy can modify the session-expires header. > > Pls provide suggesstions whether the optimisation is possible? The Session-Expires establishes the upper bound for session refresh. The Min-SE establishes the lower bound. The minimum acceptable value for Min-SE and Session-Expires could be different for proxies and the UA. See Section 3. Any proxy servicing this request can lower this value, but it is not allowed to decrease it below the value specified in the Min-SE header field. If the Session-Expires interval is too low for a proxy (i.e., lower than the value of Min-SE that the proxy would wish to assert), the proxy rejects the request with a 422 response. One reason I can think of not explicitly allowing increasing the Session-Expires is it may not be acceptable to the UAC. The cleaner approach is to reject with 422, which provides option for UAC to choose to either Re-INVITE with new Session-Expires or look for alternative routes. For UAs the Session-Expires need not add much load, but for a proxy, frequent session refresh could add significant load. You may also want to search the SIP/Sip-implementors mailing list on Session-timer. > Best Regards, > Venkatesh > > > > On 4/23/07, Bala Neelakantan <[EMAIL PROTECTED]> wrote: > > > > Responses inline. > > > > Thanks, > > Neel > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] [mailto:sip- > implementors- > > > [EMAIL PROTECTED] On Behalf Of venkatesh chandran > > > Sent: Saturday, April 21, 2007 5:56 AM > > > To: [email protected] > > > Subject: Re: [Sip-implementors] Regarding SESSION-TIMER > > > > > > Hello *, > > > Thanks for the information. > > > > > > I have some more queries, > > > 1)When INVITE send from UAC with the session-expires value less than > the > > > Min-SE configured in the proxy, the proxy will reject the INVITE with > > 422 > > > response and include the Min-SE header.After that UAC will send a new > > > INVITE > > > with session-expires and Min-SE returned in the 422 response. > > > Now when RE-INVITE send with session-expires less than Min-SE then > what > > > will > > > be the behaivour of the proxy?Again 422 will be send by proxy? > > > > > > > Yes, the situation you describe can happen, if there are multiple > proxies > > and each of them have a progressively increasing Session-Expires and > > Min-SE. > > In this scenario, it is possible that the 422's can be generated till it > > the > > value of Session-Expires and Min-SE are acceptable to all the > intermediate > > proxies. > > > > > 2)what is the real use behind the 422 response? > > > when INVITE is received with session-expires less than the min-se > > > configured > > > in proxy then the proxy can modify the session-expires to the min-se > > > configured value and forward the INVITE to terminating side and in the > > 200 > > > OK response the UAC will be indicated with the new session-expires and > > if > > > parameter refresher=uac, then uac can refresh the session considering > > the > > > new session-expires.Whether this is possible? > > > If this is applicable a INVITE may not rejected. > > > > A Proxy can not modify the SIP headers. It can only add headers. So, > > what > > you describe is an optimization, but it is violation of the RFC 3261. > > > > > > > > Pls give your points. > > > > > > Best Regards, > > > Venkatesh > > > > > > > > > On 4/20/07, Manjunath Warad <[EMAIL PROTECTED]> wrote: > > > > > > > > Please see inline... > > > > > > > > > > > > > > > > > > ************************************************************************** > > > ** > > > > *********** > > > > > > > > This e-mail and attachments contain confidential > > information > > > > from HUAWEI, which is intended only for the person or entity whose > > > address > > > > is listed above. Any use of the information contained herein in any > > way > > > > (including, but not limited to, total or partial disclosure, > > > reproduction, > > > > or dissemination) by persons other than the intended recipient's) is > > > > prohibited. If you receive this e-mail in error, please notify the > > > sender > > > > by > > > > phone or email immediately and delete it! > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto: [EMAIL PROTECTED] On Behalf > > > > Of venkatesh chandran > > > > Sent: Friday, April 20, 2007 4:53 PM > > > > To: [email protected] > > > > Subject: [Sip-implementors] Regarding SESSION-TIMER > > > > > > > > Hello All, > > > > I have the following queries regarding the SESSION-TIMER > handling. > > > > > > > > -When UAC and UAS are not supporting the SESSION-TIMER,then > > > > what will be the behaviour of call-stateful proxy? > > > > -Will call-stateful proxy still sends the SESSION-TIMER > > > > header in the INVITE that is forwarded to the terminating > > > > side with the value configured locally and handles the > > > > session-timer? > > > > -After SESSION-TIMER has expired the session and dialog > > > > details will be deleted in call-stateful proxy and BYE will > > > > not be triggered to UAC and UAS.Now how the UA's are > > > > informed about the release of the call? > > > > > > > > Session Timers in proxies are triggered and regulated (in most > cases) > > > from > > > > UA. I mean to say, if UA's support then only proxy session timer > will > > be > > > > activated. > > > > > > > > Kind Regards, > > > > Venkatesh > > > > _______________________________________________ > > > > 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 > > > > > _______________________________________________ > 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
