Re: [Dime] Question regarding diameter session

<> Thu, 29 June 2017 10:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EFBD1129459 for <>; Thu, 29 Jun 2017 03:22:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.399
X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Sj5JaxloeXfE for <>; Thu, 29 Jun 2017 03:22:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D38D127876 for <>; Thu, 29 Jun 2017 03:22:25 -0700 (PDT)
Received: from (unknown [xx.xx.xx.7]) by (ESMTP service) with ESMTP id 5D2E71604E6; Thu, 29 Jun 2017 12:22:23 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by (ESMTP service) with ESMTP id 3BB2360074; Thu, 29 Jun 2017 12:22:23 +0200 (CEST)
Received: from OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0352.000; Thu, 29 Jun 2017 12:22:22 +0200
From: <>
To: =?iso-8859-1?Q?Ivan_Skytte_J=F8rgensen?= <>, "" <>
Thread-Topic: [Dime] Question regarding diameter session
Thread-Index: AQHS8Kukdr6gFqIsx0KA7HybeC4Fb6I7bwsAgAArdVA=
Date: Thu, 29 Jun 2017 10:22:22 +0000
Message-ID: <28952_1498731743_5954D4DF_28952_242_9_6B7134B31289DC4FAF731D844122B36E21E3B2A5@OPEXCLILM43.corporate.adroot.infra.ftgroup>
References: <> <4060965.cvG7Lxnu4Z@isjsys>
In-Reply-To: <4060965.cvG7Lxnu4Z@isjsys>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Dime] Question regarding diameter session
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Jun 2017 10:22:27 -0000


Please see below.



> -----Message d'origine-----
> De : DiME [] De la part de Ivan Skytte Jørgensen
> Envoyé : jeudi 29 juin 2017 11:21
> À :
> Objet : Re: [Dime] Question regarding diameter session
> On Thursday 29 June 2017 13:15:05 Ajinkya Joshi wrote:
> > Hello,
> >
> > >From the RFC 6733, it is clear that diameter session is identified
> > >bases on
> > session-id, which has to be globally unique. Also in section 2.5
> > (Connections vs Sessions), it's clearly mentioned that one connection
> > can be used to multiplex multiple diameter sessions.
> > I have following questions related to diameter session -
> >
> > Is there any implicit correlation between diameter session and origin-host?
> Only what is spelled out in the RFC "The Session-Id MUST begin with the sender's
> identity [...]"

[LM] correct.

> A dubious diameter implementation may decode the session-id extracting what
> the origin-host might be. But that would be silly since it is already present in the
> origin-host AVP. Well-behaved diameter implementations treat session-id as an
> opaque string.
> > Does diameter standard allow different requests for the same session
> > to have different origin-host value?
> Yes, eg RAR and ASR requests will have a typically have an origin-host/realm
> different from where the session-id was created.

[LM] if the question was for requests with different origin-host received by the same server for the same session, the answer is NO.
Session related data maintained by a server for a given session are bounded to a single Origin-host. As said in the RFC6733, 
  "A session is a
   logical concept at the application layer that exists between the
   Diameter client and the Diameter server; it is identified via the
   Session-Id AVP."
There is therefore a 1-to-1 relationship between the server and the client initiating the session. If a server would accept session related messages from different nodes for the same session, it would not possible to ensure a consistent management of the session state, e.g. node A creating the session, node B terminating the session whereas node A is not aware. 

> /isj
> _______________________________________________
> DiME mailing list


Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.