Subject: Re: [Dime] Command re-use, setting of Session-ID AVP

From: Marco Liebsch <[email-masked]>
Date: Mon, 4 Mar 2013 15:31:48 +0000

Hi Lionel,

please inline.

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Donnerstag, 28. Februar 2013 11:45
>To: Marco Liebsch; [email-masked]
>Subject: RE: Command re-use, setting of Session-ID AVP
>
>Hi Marco,
>
>I think that the simplest approach would be to use the session-ID as it is, without
>impacts of the concept of group. That is, each message should be first related to
>a given session (identified by the session-id AVP). The group management will be
>done using the dedicated new AVPs. Therefore, it is completely transparent for
>nodes not supporting the concept of group, especially proxies that could be in
>the signaling path.

Yes, if we treat grouping AVPs separately and informational, we can enable
the Single-Session-Fallback as indicated in the previous mail. 

Btw "proxy": There was an issue with stateful proxies and group operations, which
has been addressed on the ML some time ago. It was about the case where Diameter
sessions have been set up via different proxies, hence states are distributed between
multiple proxies. A group session termination will allow terminating (a subset of the group's)
states solely on a single proxy which forwards the group message. Other proxies will not see
that group message, unless the server keeps a record of the proxy and sends multiple group
session termination commands, one though each proxy. But that causes that the Client will
receive multiple group session termination requests.. Not really clean.

marco

>
>Regards,
>
>Lionel
>
>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de
>Marco Liebsch Envoyé : mardi 19 février 2013 16:50 À : [email-masked] Objet :
>[Dime] Command re-use, setting of Session-ID AVP
>
>Hi,
>
>the latest proposal to enable Diameter to signal group commands re-uses
>existing Diameter messages and adds new group-specific AVPs to the command.
>
>How to set the session's mandatory Session-ID? It has a fixed location in the
>message and message parsing may rely on the value of the Session-ID AVP as
>key to lookup a particular session's entry in the local database.
>Group-Session-ID AVP(s) may follow the mandatory Session-ID.
>
>Now, the mandatory Session-ID AVP could hold the following values:
>
>+ All-0 or any other not allocated value: Probably not conform to
>+ standard
>peers which do not support group operations
>
>+ Group-Session-ID: Previously agreed with the peer. May conflict with
>+ the original
>definition of the Session-ID to hold a single session's ID.
>
>+ Single Session ID of a session which is part of the previously assigned group.
>Would allow fallback to process the command for a single session only.
>
>Any comments?
>
>marco
>
>
>
>_______________________________________________
>DiME mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dime
>
>_________________________________________________________________
>________________________________________________________
>
>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, France Telecom - 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, France Telecom - Orange is not liable for messages
>that have been modified, changed or falsified.
>Thank you.