IETF Logo Mail Archive

Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question

Ranjit Avasarala <ranjitkav0811@gmail.com> Mon, 13 June 2016 21:30 UTC

Return-Path: <ranjitkav0811@gmail.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 7A96712DA55 for <dispatch@ietfa.amsl.com>; Mon, 13 Jun 2016 14:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5j4YJgeYMZVt for <dispatch@ietfa.amsl.com>; Mon, 13 Jun 2016 14:30:12 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF43212DA4B for <dispatch@ietf.org>; Mon, 13 Jun 2016 14:30:11 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id n184so95822342wmn.1 for <dispatch@ietf.org>; Mon, 13 Jun 2016 14:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8bLbkx6v3+dPB98QTCwHCfQ27kbF3w2XR2XZyUWWYmU=; b=rHzTJ3DLPEQr3cEhbdWsC2wUIPupJ1xxiiy442yDDEhiEZxy/bNj51D05rAiSADxWP yeZox3PxvHA5l+FsMHLuRO1ulSKlH7sE83GK1Q2CkviZrdpeksAP0QZ8pygL8lpwwucW LTcqnP8Zy26OTLZORDLhfbwKQX+X7FSMMaVFjYoIJZiYCxzHg1lJguuE3U3Bu1cPatSq 0dSXMPdCJcyHPSJBx3jaOt5/HQKUxqpKbhcHfm4+4nqzRNQQdkX3WJw+Kg3DG8WiWBGX KuC48z+M8SrhbFWD4sHKmq5ThYUqQKnZdukNCTAmW5bc1aJJW/VxvHLYuE3ercxvwQlw LihQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8bLbkx6v3+dPB98QTCwHCfQ27kbF3w2XR2XZyUWWYmU=; b=Ob5oH3xcpHaTCYw2+9xAIK04VCWAojRWek483GhFacdBgq66K2qVOtbDeEz8Cd+pzG ZcdtuL+xKRehLDeZQK8LlQ1xz6NRm2v6Mpi06xy2WllEHPm2EIbSFkwOBQ+36O6iOiBJ jTVlwd5GXElOTS+9Y3PVcj1bOEv4yjHfGj15g4ZepVcom6FNntw5SieeHGLXvmmT1ln2 rixkzy9XjnkxBI6RYnD7hvn31/NLTwYZ7fk31AJJiXKEmNOAnygUyULleMLeDqzC0xXs O5gcSLhpNswVmlaWm4wDr2DuPRB2qRIV95sXalKIo67uuwoqb2Aj+aCdA3lFyjy6tjVI z/eg==
X-Gm-Message-State: ALyK8tLlpfAb9MmcOP7Yyxv30ALSCEKzn1BPGmbkMgwR3EPGDhXbU6tNViEUs507+TCbrhym4FfAtDwxOB/sVQ==
X-Received: by 10.28.150.138 with SMTP id y132mr2951563wmd.103.1465853410527; Mon, 13 Jun 2016 14:30:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.80.100 with HTTP; Mon, 13 Jun 2016 14:30:09 -0700 (PDT)
In-Reply-To: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com>
References: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com>
From: Ranjit Avasarala <ranjitkav0811@gmail.com>
Date: Mon, 13 Jun 2016 16:30:09 -0500
Message-ID: <CA+CMEWcMAiRxbQX1CnGUiHBMA7PSctmJ5AfKmyr7So+B5-5e0Q@mail.gmail.com>
To: "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" <sunsinha@cisco.com>
Content-Type: multipart/alternative; boundary="001a114b3b0cd3cf5505352f975e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/8x4EGyg6SlErCQ-92asJEr45dwo>
Cc: dispatch@ietf.org
Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 13 Jun 2016 21:30:14 -0000

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

Thanks
Ranjit








On Mon, Jun 13, 2016 at 1:51 PM, Brett Tate <brett@broadsoft.com> 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
>

v2.23.0 | Report a Bug | By Email