Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question
"sunil kumar sinha" <sunilkumarsinha9@rediffmail.com> Wed, 22 March 2017 08:33 UTC
Return-Path: <sunilkumarsinha9@rediffmail.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6813E129636 for <dispatch@ietfa.amsl.com>; Wed, 22 Mar 2017 01:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level:
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=rediffmail.com; domainkeys=pass (1024-bit key) header.from=sunilkumarsinha9@rediffmail.com header.sender=sunilkumarsinha9@rediffmail.com header.d=rediffmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_7XsI_BNzl0 for <dispatch@ietfa.amsl.com>; Wed, 22 Mar 2017 01:33:44 -0700 (PDT)
Received: from rediffmail.com (f5mail-224-118.rediffmail.com [114.31.224.118]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0289131532 for <dispatch@ietf.org>; Wed, 22 Mar 2017 01:33:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rediffmail.com; s=mail; t=1490171617; bh=qHdP232Yr/qMm+IAN7RwMLBYyAVXTB0AVx/hJzmyrk0=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=AeZ2oSsF0nVA7oAJk3QHZZNsfvjiumSugp0RausfnxC7erjHLRGLlNZr3xwi165Fp UPO0/gwfah5ZpC0tWWAGWSialxqfWEWjccMaUmr4kmsCNfvVtu3vEx7aDtUHGrgN4d ouQPk4xOBSIsiFd1sWhTmzB+ikCTA2TIn8jgFKQQ=
Received: (qmail 2882 invoked by uid 510); 22 Mar 2017 08:33:37 -0000
Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=hw5sFnaFq2ZnyGuIsGundvDOoIEyV7kuABmMsdGgP5rW2q6sC/WyakZCE4Q+WW0zsv9aIavUGDXwerDB7kbcqBq6FqV+ILtrKiWzPpc+pPoFbKKPluen1A+dJwsRyQ3N1f7Wo+mT9k/s5u6Nrbp6YjAOes/VoKwkY80WT4y0Ue0= ;
x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd;
X-OUT-VDRT-SpamState: 0\LEGIT
X-OUT-VDRT-SpamScore: 0
X-OUT-VDRT-SpamCause: gggruggvucftvghtrhhoucdtuddrfeelhedrjedtgddufeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecutffgfffkhffhpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepffggvffkjghsuffhtgesrgdtreertddtjeenucfhrhhomhepfdhsuhhnihhluchkuhhmrghruchsihhnhhgrfdcuoehsuhhnihhlkhhumhgrrhhsihhnhhgrleesrhgvughifhhfmhgrihhlrdgtohhmqeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppeduvddurddvgeegrdduvdehrddujedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht
X-Remote-IP: 121.244.125.170
X-REDF-OSEN: sunilkumarsinha9@rediffmail.com
Date: Wed, 22 Mar 2017 08:33:37 -0000
MIME-Version: 1.0
To: ranjitkav0811@gmail.com
Received: from unknown 121.244.125.170 by rediffmail.com via HTTP; 22 Mar 2017 08:33:37 -0000
X-Senderscore: D=0&S=0
Message-ID: <1465853420.S.12274.8910.f5-224-165.1490171617.2672@webmail.rediffmail.com>
In-Reply-To: <CA+CMEWcMAiRxbQX1CnGUiHBMA7PSctmJ5AfKmyr7So+B5-5e0Q@mail.gmail.com>
Sender: sunilkumarsinha9@rediffmail.com
From: sunil kumar sinha <sunilkumarsinha9@rediffmail.com>
Cc: sunsinha@cisco.com, dispatch@ietf.org
Content-Type: multipart/alternative; boundary="=_701b465befe7cbb09f41ff3676d30a81"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/7LcaP3t6KjWBjz6B99gxdDT8Ji4>
Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2017 08:33:46 -0000
Hi Ranjit, I have tried to answer your valuable comments. Please find response inline below. Section 1 1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandatory headers and not 6. E.g To, From, Call-ID, CSeq, Contact, Max-Forwards and Via. In addition there could be more headers like Content-Type, Content-Length, etc [Answer] Thanks for pointing out blunder mistake. It will be corrected in next version. 2. Instead of jointly - which actually is used for 2 headers and not for many. so you should use the word - together or all of them . [Answer] It will also consider and corrected in next version. 3. Also I don't think the main motivation of providing more headers in a SIP message is to actually find a facility though the actual intent is to better describe the session or indicate support for a certain capability or service and mandate some feature (long list...) [Answer] : Ok 4. Also I do not think we can conclude whether the headers are needed or not before and after session is established. every header that is part of the SIP message has certain significance and it is put if there is a need. so we can not generalize saying that prior to session establishment more headers are needed and after session less. [Answer]: User Agent is free to add header when and wherever it is MUST in the session. Our suggestion is that once the dialog is established, only those optional header(s) will be present in the subsequent request or response whose attribute is changed. It will NOT applicable to seven mandatory headers i.e. To, From, CSeq, Call-ID, Max-Forwards, Via and Contact. 5. if you think it is burden on the bandwidth, the messages can be compressed. [Answer] Correct, compression is one good options. But it will not reduce the number of options headers. Our idea is to keep the minimum number of header after the dialog is established. This is because the larger message size take significantly more CPU cycles and memory for both parsing and producing. Thus, reducing message size would increase through put. At the same time it will also reduce the network burden. Thanks & Regards, Sunil Sinha On Tue, 14 Jun 2016 03:00:20 +0530 Ranjit Avasarala wrote >Hi Sunil my initial comments on this draft Section 1 1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandatory headers and not 6. E.g To, From, Call-ID, CSeq, Contact, Max-Forwards and Via. In addition there could be more headers like Content-Type, Content-Length, etc 2. Instead of jointly - which actually is used for 2 headers and not for many. so you should use the word - together or all of them .3. Also I don't think the main motivation of providing more headers in a SIP message is to actually find a facility though the actual intent is to better describe the session or indicate support for a certain capability or service and mandate some feature (long list...) 4. Also I do not think we can conclude whether the headers are needed or not before and after session is established. every header that is part of the SIP message has certain significance and it is put if there is a need. so we can not generalize saying that prior to session establishment more headers are needed and after session less.5. if you think it is burden on the bandwidth, the messages can be compressed. More comments as I review ThanksRanjit On Mon, Jun 13, 2016 at 1:51 PM, Brett Tate wrote: Hi, The following are a few comments concerning draft-sunil-sankar-dispatch-sip-incr-00. Thanks, Brett ------ 1) The draft should clarify the relation to SHOULD and MUST within other RFCs concerning header inclusion. Section 6.1 appears to indicate that you can ignore MUST statements within other RFCs concerning the need to include a specific a header. However, I'm currently unsure if section 4 next-to-last sentence supports or conflicts with that mandate. 2) You might want to reword section 4 to use normative language. 3) How would this draft interact with RFC 4028 from refresh -versus- deactivation perspective? 4) How would this draft interact with draft-ietf-insipid-session-id since the presence of the Session-ID is to help debug the call flow? 5) You should clarify that transaction specific headers such as Supported, Require, Proxy-Require, and Content-Length need to be included again. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
- Re: [dispatch] draft-sunil-sankar-dispatch-sip-in… amar deep
- Re: [dispatch] draft-sunil-sankar-dispatch-sip-in… sunil sinha
- Re: [dispatch] draft-sunil-sankar-dispatch-sip-in… Cullen Jennings (fluffy)
- Re: [dispatch] draft-sunil-sankar-dispatch-sip-in… Ranjit Avasarala
- Re: [dispatch] draft-sunil-sankar-dispatch-sip-in… Neelakantan, Neel
- [dispatch] draft-sunil-sankar-dispatch-sip-incr-0… Brett Tate
- Re: [dispatch] draft-sunil-sankar-dispatch-sip-in… sunil kumar sinha