Re: [Sip] Reg. refresher param in 2xx response

Harbhanu <harbhanu@huawei.com> Tue, 18 May 2010 14:09 UTC

Return-Path: <harbhanu@huawei.com>
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95283A6A31 for <sip@core3.amsl.com>; Tue, 18 May 2010 07:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.332
X-Spam-Level:
X-Spam-Status: No, score=0.332 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh5UU1bVyDO1 for <sip@core3.amsl.com>; Tue, 18 May 2010 07:09:29 -0700 (PDT)
Received: from szxga01-in.huawei.com (unknown [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 0DABA3A6887 for <sip@ietf.org>; Tue, 18 May 2010 07:09:15 -0700 (PDT)
Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2M00BHBCMWA6@szxga01-in.huawei.com> for sip@ietf.org; Tue, 18 May 2010 22:08:57 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L2M00HBBCMWNW@szxga01-in.huawei.com> for sip@ietf.org; Tue, 18 May 2010 22:08:56 +0800 (CST)
Received: from BLRNSHTIPL1NC ([10.18.1.31]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L2M00E5HCMVP3@szxml06-in.huawei.com> for sip@ietf.org; Tue, 18 May 2010 22:08:56 +0800 (CST)
Date: Tue, 18 May 2010 19:38:55 +0530
From: Harbhanu <harbhanu@huawei.com>
In-reply-to: <747A6506A991724FB09B129B79D5FEB614815B6E27@EXMBXCLUS01.citservers.local>
To: 'Brett Tate' <brett@broadsoft.com>, sip@ietf.org
Message-id: <CC7B5CD68EBD4D7DB2CB888E9B55334D@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.4325
X-Mailer: Microsoft Office Outlook 11
Content-type: multipart/alternative; boundary="Boundary_(ID_dGID94fngTxPxLlGyY+p0g)"
Thread-index: Acr2ZuRMSu4+qoDaR7qbmzSKijoBigAG+8eQAAN99eA=
References: <0C4DE8BD80D149D2BC3D940CA05CE74F@china.huawei.com> <747A6506A991724FB09B129B79D5FEB614815B6E27@EXMBXCLUS01.citservers.local>
Subject: Re: [Sip] Reg. refresher param in 2xx response
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 14:09:34 -0000

Precisely, IMO too RFC doesn't specify UAC behavior for this situation.

So, we think that in order to have a better error tolerance or say
flexibility, this behavior SHOULD be fine.

 

So can anybody suggest/highlight any scenario/use-case wherein this
'tolerance' might prove otherwise? :-)

Also, please specify if you are aware of its handling in any of the
commercial implementations.

 

Thanks again!!

 

Regards,

Harbhanu

 

****************************************************************************
************************************************************************
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!

  _____  

From: Brett Tate [mailto:brett@broadsoft.com] 
Sent: Tuesday, May 18, 2010 5:46 PM
To: Harbhanu; sip@ietf.org
Subject: RE: [Sip] Reg. refresher param in 2xx response

 

If 2xx's session-expires doesn't contain the mandatory refresher parameter,
it is likely because interworking with an old implementation of the draft:

http://tools.ietf.org/wg/sip/draft-ietf-sip-session-timer/

 

The refresher parameter was added within version 5 of the draft.

 

Per RFC4028, it is an abnormal situation; I don't recall the RFC indicating
how to act within the abnormal situation.  Thus you can however you want.

 

From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of
Harbhanu
Sent: Tuesday, May 18, 2010 4:49 AM
To: sip@ietf.org
Subject: [Sip] Reg. refresher param in 2xx response

 

As per 4028, for the following case UAS MUST specify the refresher parameter
in 2xx response.

 

UAC ----INV ----> supported=timer, SE=90-----> UAS

 

UAC <----2XX INV -- SE=90- ---------------- UAS

 

[Section-9, page-16]

The UAS MUST set the value of the refresher parameter in the Session-Expires
header field in the 2xx response.
 

But IMO when UE sends response for INVITE and it adds Session-Expires but
doesn't specify the refresher parameter.

Then in this case UAC can safely assume that, either the UAS doesn't support
session-timer or it doesn't want to act as a 'refresher'.

 

So instead of sending a BYE UAC MAY treat this as a buggy/naive UE & hence
"UAC" SHOULD act as 'refresher'.

 

Please share your opinion. Thanks!

 

Regards,

Harbhanu

 

****************************************************************************
****************************************************************************
*********************************
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!