Re: [sipcore] RFC4028 : Very basic question in 8.1

Roman Shpount <roman@telurix.com> Thu, 09 July 2020 13:17 UTC

Return-Path: <roman@telurix.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B503A09E9 for <sipcore@ietfa.amsl.com>; Thu, 9 Jul 2020 06:17:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 6K9w6hC4tcJM for <sipcore@ietfa.amsl.com>; Thu, 9 Jul 2020 06:17:19 -0700 (PDT)
Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 BE7103A09E0 for <sipcore@ietf.org>; Thu, 9 Jul 2020 06:17:19 -0700 (PDT)
Received: by mail-ot1-x32d.google.com with SMTP id g37so1643301otb.9 for <sipcore@ietf.org>; Thu, 09 Jul 2020 06:17:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3cW7ieuXxdVENXmT5Jfs1mtC1E6OxVOKQl3XSjr+vqg=; b=XiagLZPyDxDGM4eTCBX/JE67t8HCcoVSGMLR3YJyw+Ejb8OJSz136hrXDV/rYUGU4Z 2L3drGirShnAocRhttW3BvS1nLJyIkljYKVH5GFw7F/yA6SUppyMWtDuu2BF85BRtykj 0dYFc2GtK9zJ0DxgT0gUQdMCLU6Fs1z9qVmkFWppsEnJbOkpoRVqsdRD0cJTd42f/2Zc DHKZFNTsXV1cgoqFRryI/OqW0RPQRRVdinYl+IrhSUZsWNhUDxWxgIOvbAOgXPg5BMzO BoA899T+z24P2ZYBW7NnAEVF5VCon5J/uNgJoaZjT6mUWntBPd+5oNaiVufm5v0/9IlX ArPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3cW7ieuXxdVENXmT5Jfs1mtC1E6OxVOKQl3XSjr+vqg=; b=rqv9Tx2+IKKnhdoohA6wlsWyabvKCchzhcYxIvWYFofHxxY/4al+rfiffv6uPCvsEn fGGKS5pGtTrCfciJhNIBD/zXDeZ6V34gIRC7toqxT+tqC8/Qd1A48jASu/sCK43LJHnn uMrm2vI5hx0JTLg2y0JGCl8jNGQgVoH8tgVx7lgGrrZfSADJ79N8OxPRkhJQboSybAiM cgKdG47R440b8RMBgJnj3ncpWUqAPtV58HjJEO82LSzKZcES7j8gPuJv5x5pei5f32Gh qaEjxZxwyCGOAxBB1SUksZwGj7NL0jUf5vMq0FRWYxjxpvAlouEcv2itBiTOAX6PaJ2I AOkQ==
X-Gm-Message-State: AOAM531gRSGwA6c4uAGG+Kn7vfaCmGr+cPMx5fQUAw68m0ZbvLOzkSjx oWDKh2Mdjm2XpvHP/6o9adFCQ/mhMYo=
X-Google-Smtp-Source: ABdhPJwHNwBszAMGBzXp4tJOqcF3NwN71YksAitKfjN1R9VZ4LA8DTpnvjQWIicpXcI9TcnhYXdFLQ==
X-Received: by 2002:a9d:24e6:: with SMTP id z93mr53396292ota.360.1594300638258; Thu, 09 Jul 2020 06:17:18 -0700 (PDT)
Received: from mail-oi1-f173.google.com (mail-oi1-f173.google.com. [209.85.167.173]) by smtp.gmail.com with ESMTPSA id x5sm510161oic.21.2020.07.09.06.17.17 for <sipcore@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 09 Jul 2020 06:17:17 -0700 (PDT)
Received: by mail-oi1-f173.google.com with SMTP id k22so1863903oib.0 for <sipcore@ietf.org>; Thu, 09 Jul 2020 06:17:17 -0700 (PDT)
X-Received: by 2002:a54:4e1d:: with SMTP id a29mr11494333oiy.139.1594300636981; Thu, 09 Jul 2020 06:17:16 -0700 (PDT)
MIME-Version: 1.0
References: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com>
In-Reply-To: <24d093f2-284f-a068-1cf1-8fb1b9310ff0@gmail.com>
From: Roman Shpount <roman@telurix.com>
Date: Thu, 09 Jul 2020 09:17:04 -0400
X-Gmail-Original-Message-ID: <CAD5OKxu1Ua79rEg-udgD-RxZjrfTmmyZMmDGvPQXp5xc1kzn1Q@mail.gmail.com>
Message-ID: <CAD5OKxu1Ua79rEg-udgD-RxZjrfTmmyZMmDGvPQXp5xc1kzn1Q@mail.gmail.com>
To: OKUMURA Shinji <ietf.shinji@gmail.com>
Cc: SIPCORE <sipcore@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000021ee9e05aa020b6f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/sroBEzjsdyIcNLdxKS6ZRQT94Ig>
Subject: Re: [sipcore] RFC4028 : Very basic question in 8.1
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2020 13:17:21 -0000

Shinji,

This is a negotiation where all parties (UAC, UAS and proxies on path) must
agree on the session timer value. Min-SE is the minimum allowed value. SE
is the maximum allowed value. If Proxy needs a higher SE interval, it needs
to renegotiate maximum allowed session timer value with all the parties
upstream. This is why it rejects the request with 422 and a higher Min-SE
value.

BTW, there is no guarantee that session timer negotiation will succeed. In
general case it is possible that session timer requirements for all the
proxies UAC and UAS cannot be satisfied at the same time.

Once again, may I ask, what is your motivation for proposing this change?
Are you seeing an issue with a deployment somewhere?
_____________
Roman Shpount


On Thu, Jul 9, 2020 at 9:10 AM OKUMURA Shinji <ietf.shinji@gmail.com> wrote:

> Hi,
>
> This is very basic question.
>
> Why must a proxy not increase SE-value?
>
> 1. UA sends INVITE(SE:100)
> 2. proxy rejects INVITE with 422(MSE:200)
> 3. UA sends INVITE again.(SE:200)
> 4. proxy forwards INVITE(SE:200)
>
> +-----+             +-------+            +-----+
> | UA1 |             | Proxy |            | UA2 |
> +-----+             +-------+            +-----+
>     |                    |                   |
>     | INVITE(SE:100)     |                   |
>     |------------------->|                   |
>     |                    |                   |
>     |       422(MSE:200) |                   |
>     |<-------------------|                   |
>     |                    |                   |
>     | INVITE(SE:200)     |                   |
>     |------------------->|                   |
>     |                    |                   |
>     |                    | INVITE(SE:200)    |
>     |                    |------------------>|
>
> If proxy may increase SE-value,
> 1. UA sends INVITE(SE:100)
> 2. proxy forwards INVITE(SE:200)
>
> +-----+             +-------+            +-----+
> | UA1 |             | Proxy |            | UA2 |
> +-----+             +-------+            +-----+
>     |                    |                   |
>     | INVITE(SE:100)     |                   |
>     |------------------->|                   |
>     |                    |                   |
>     |                    | INVITE(SE:200)    |
>     |                    |------------------>|
>     |                    |                   |
>
> Needless to say, this sequence is much simpler.
>
> Regards,
> Shinji
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>