Re: [core] Using CoAP for P2P

Christer Holmberg <> Mon, 06 April 2020 11:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A38D13A0EE2 for <>; Mon, 6 Apr 2020 04:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.167
X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.168, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Sc5cfp6xqHN for <>; Mon, 6 Apr 2020 04:25:58 -0700 (PDT)
Received: from ( [IPv6:2a01:111:f400:7e1a::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D1A33A0EDC for <>; Mon, 6 Apr 2020 04:25:57 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=Kn1sNpC/u5FGmANSczmUvlcahc8BoQ+2KaUufaZPTZr0cuCQA/1Ag3gVzK9Df6l6TTqAZmySTJZFAAgo8TYFRfucGaTGVwLoRkTw732b2lsUJHhEZFKNaJXkBNxYJzN0YhPOQbIGsOixjWu+fDDfdnOyG5znA0VEkTGDsck5e6kgTFbn/UThCq51q/SBxVwsUGTXyMSqw7Tvv0mbL/xSO0TA/NRo+++NEzxBjly6ND4UiWi4dOq+KRxuFVO87DnE/o1aAgQYHcAfds2gStL1EnVDky/DKWGTiuls7yo0JY2yanUv1Y+gRVpKHPq7Acu4ieN6IXlC+yE8OA804SGx5A==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NcF+a6l77hXOcrvQehQiGE5H6JzOuZE5yla6COSa+/0=; b=bqoEBNZxtS4pQk+vbXNF4geSY7338GRGz5kTyjlumEOi5PDmHgtqSPiApFZmglm5Pyiw4V1DxtpYJZgcQ+jkSBNslR39xWxVOq3+QsegDMIw5GT45wQEf8ffi5MxbpRNMul+oj4aZj2o1iE1uDPS2EBS3xXgBedtnUau7xrSllS3aYP6fqvlN5zMb/SjpCFE2YDARZ+LJ/rLsVZeXlibABB+uFbSoW4Igk631R6WUwCyvR/Z8UYH+Z7e1GsnxA46Hg1JhWUnDcwlebd0+h8P0lB0v2swcXfUoo3gb0G2X8KBWjVM61HNyajoNJopuYWXG6fMhEz4M7A7vuKB3XTSWg==
ARC-Authentication-Results: i=1; 1; spf=pass; dmarc=pass action=none; dkim=pass; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NcF+a6l77hXOcrvQehQiGE5H6JzOuZE5yla6COSa+/0=; b=T7cXwTTwsaN8a77zeYcfh8oDVZddRRzHtqKUv47Itnuya0vgjPAbTLSD2PpUofqwEl4twl388kPiCVdgMTtUS4fZUOCvWATRtmzghX9A6eYJe76lLbiHllCDE6/uFd3RhXQSI6zG1N0lcatJeAakksjdnjSDVg98V3hLsmzHEWU=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2900.14; Mon, 6 Apr 2020 11:25:55 +0000
Received: from ([fe80::57b:b81e:33ec:5512]) by ([fe80::57b:b81e:33ec:5512%7]) with mapi id 15.20.2900.012; Mon, 6 Apr 2020 11:25:55 +0000
From: Christer Holmberg <>
To: Abhijan Bhattacharyya <>
CC: Thomas Fossati <>, core <>
Thread-Topic: [core] Using CoAP for P2P
Date: Mon, 6 Apr 2020 11:25:55 +0000
Message-ID: <>
References: <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-GB
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 389c5c8f-baee-43d8-afeb-08d7da1d45b8
x-ms-traffictypediagnostic: AM0PR07MB6131:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0365C0E14B
x-forefront-antispam-report: CIP:; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM;; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(396003)(376002)(366004)(44832011)(53546011)(66476007)(66946007)(6506007)(2906002)(8936002)(6486002)(33656002)(186003)(66446008)(64756008)(66556008)(76116006)(86362001)(478600001)(36756003)(2616005)(5660300002)(81156014)(71200400001)(966005)(81166006)(316002)(54906003)(26005)(66574012)(6512007)(6916009)(4326008)(8676002); DIR:OUT; SFP:1101;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VG6VkZ4xXSgl/JJo5gEwGfczJuy/mj/uNE+b4uzbM76Kb3i5U1zsK38KD8IQh9MIORI3VWumQgSHXsylz3yM1sxraSX25FmusuuxLeE2zjMgg5qbs9Z0GAN0lz9b3EulL6M9o61DkVe39o1fRLNFEU2vJ9X2rpRvrzEJADwoS2LoPzJ4lrAPFJsCUw46QOBHf1JYfTxYYN/m1Qky39m+e7FXf3+b8rE0ybAIGx+9nddYoS8friPaGKAtOTvQKUhu7GrleRbN6Ck2Ea/+B9EaFHGmjchOAW1lvJcyYzKloWwM00yVCmc6UTitcFkWqThHb5EJsCR+xXiPbm0eRBs4PmuFBudrAQwSN8oCVxOeGoIOjkOpGcldoC599N7J6QZ0y5X+tpP+2z/2SPH8LzxGeezaX9yPNaa8F/q2dyS628VCRda46Eeb4lT5X+JGFgAEMrY+oQ54E6awoAn8mBY6obdwz8G7QCRJyUCWjALfffpAOfux99hF1uXSyVmrUXrEpZoLJOzMm++pOd7wZ48YUw==
x-ms-exchange-antispam-messagedata: 5c9fEiMqADcCwLXr1jpk3PbL2JNZ5tzqKcPfEMAtNGeOsS/2lBzmBW3Xqbo/zH8CQjyY/BFUqSwKCmr0gcqNy/VmBIzlp1bq1uJbP45GwUZCsvvy4z5HKs/SCQZDW+2FOIauLoiYWisZvv8+C8D/Ww==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_7DA395A70A3E4EC79F2AD37FDEA2AB5Cericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 389c5c8f-baee-43d8-afeb-08d7da1d45b8
X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Apr 2020 11:25:55.3883 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: eEXfmdGgYYyLyFTeS+geLi/GsBfAE7RmlM+EgKx2sikxa0Y4px2EILns/SXhxcl3HBh53djXNFY3BujrkggIPb4SrJqpMvlECISzqpH7Azs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB6131
Archived-At: <>
Subject: Re: [core] Using CoAP for P2P
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Apr 2020 11:26:01 -0000


> Probably what can  be standardized is a method for signalling and exchanging the ICE candidates so that end nodes can
> mutually push the data to the other. Signalling may include resource discovery.

Yes, one could split things up into separate pieces as far as standardization is concerned.

One piece is to simply collect candidates using CoAP. Another piece is the candidate exchange.

> Your proposal looks useful for the purpose. Extending the example towards two sided exchange might help.

Sure. If this would be standardized, that should at least be considered.

> We shall be interested to try it out if there is any open-source implementation.

Me too :)



On Sat, 4 Apr 2020, 17:56 Christer Holmberg, <<>> wrote:

>A bit of more inputs:
>We proposed a delay-sensitive time-series streaming mechanism by extending CoAP and presented in last Bangkok IETF. We called it A-REaLiST (Adaptive RESTful Real-time Live Streaming for Things).
>The draft is here:
>The relevant research work was published in 2018 Globecom workshop: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Kumar Rath, Arpan Pal: "Improving Live-Streaming Experience for Delay-Sensitive IoT >Applications: A RESTful Approach" (

What exactly do you want to standardize? As long as one device acts as a client, and the other as a server, the current mechanisms should work.

Now, if you want to send GETs etc in both directions, I assume that each endpoints would act as both client and server.



On Fri, Apr 3, 2020 at 12:11 AM Christer Holmberg <<>> wrote:

If you are interested in P2P, you might be interested in the thin-ICE presentation that was given at the T2TRG meeting in Singapore:<>



From: core <<>> on behalf of Abhijan Bhattacharyya <<>>
Date: Thursday, 2 April 2020 at 11.04
To: Thomas Fossati <<>>
Cc: core <<>>
Subject: Re: [core] Using CoAP for P2P

Hi Thomas,
What I am looking at is a situation where I have two nodes each having a time-varying resource. Both want to push the states of the respective resource to the other node within a common application context. However, these exchanges are naturally asynchronous. May be I can think of it more like a chat. A typical client-server or observe relationship will not serve the purpose. Actually both should have a client and server instance running under a common application. Then either each can *observe* the other, or can *post* the other. That is how we can do that without a central server.

If my understanding is right, according to CoAP specification, the nodes which can have both server and client (to the origin server) are "intermediary" nodes. The only example of "intermediary" considered in the spec is the proxy node. But, anyway the situation in this case does not concern with intermediary. Both are origin server and end-client together.

Is there any standardized mechanism to handle this situation?


On Wed, Apr 1, 2020 at 5:32 PM Thomas Fossati <<>> wrote:
Hi Abhijan,

On 01/04/2020, 12:31, Abhijan Bhattacharyya <<>> wrote:
> Is there any standardized mechanism to use CoAP for a P2P connection?

Not sure whether RFC 7650 would fit your needs but worth having a
look -- if you haven't already.


IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

Abhijan Bhattacharyya,
Technologist by profession [IoT| Internet Protocols| 5G]

Abhijan Bhattacharyya,
Technologist by profession [IoT| Internet Protocols| 5G]