Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 07 January 2020 16:53 UTC

Return-Path: <christer.holmberg@ericsson.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 DF476120832; Tue, 7 Jan 2020 08:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 6TJpTx11oYPD; Tue, 7 Jan 2020 08:53:35 -0800 (PST)
Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20078.outbound.protection.outlook.com [40.107.2.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C3F112081A; Tue, 7 Jan 2020 08:53:34 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ELT1Loc6g8aIlwIsJtcxk5B2amdzpniZmMOTSF1WIuNul4k88KlNKmiW/ksWqrNGfxm9KSqDhw3lJFSHsm/OHLcA5/1tvMt+trehQbg3T6b2yH+SMu+IzcbyfvifoFGav2vVfy+boNGHfxXPjknPYJABLA/lgAfWI2SStjKcaZlpyjAXe/JXcI97QJ08Bf9nNVSD9KazADL9IYub8t+bM3FUoXkEekcQi6bc7/+nZ5xiZSWviIHSImBSK2GFXFbXhZKFWvA2c1LtuQe59i3VSUCD8V0YeAGJJy7nzZMa0KjFh6RlZjqHKp/1xuWwzOlMmMbdQlRRsidAXb2xubBpdg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xqa/BY82gNC9BSg0iEOPMRqB+s5ilhROCdo/K1hV/rc=; b=MU7BkXr4/lhKKLyK0twhrhjTJPXkZh+sX72AY1qwU3b8GyRT95O4G8Kakhw/AC/H4WXypx8wVb1jevCM48qjuh0Jhin/88vyZuMq00ErsDCj+oML6of0GPfk6yKFH20S1W6mYgZVsRXFnRkVrK6dnZV2XJjvMrGrtfsFyePQ0RqR94f124BB3c3C0/dT56C4BBYyKHJhL2sYEgPmibMjSPed526BB19ImlWQD+j+1tvc+dmnM1cQQ8p0AbqTbF8uO99vBtLVm6VpOPP2koJInSi/SFx+xCrvQV9b5NPS/29rsB7czZHgFvy0OOs1PDulWUs/+d8WGLkuvaoxDM+WVg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xqa/BY82gNC9BSg0iEOPMRqB+s5ilhROCdo/K1hV/rc=; b=sMyOU/eszVLIbzoqcGj8JpKTuSOW64YuOIexchKpLj2XgA1zQ5xPGH6/RH/1huXozrKMPOeuC77ekkqmaJ0/ykDL3pxNGKVjXYsv4uwYCiCpfxWoYFfDBTcjwRONxe1elp8qGApsvwXQWwgQuUU2QkxYNnzlM4jZQL0gP9H7gI4=
Received: from AM0PR07MB3987.eurprd07.prod.outlook.com (52.134.82.159) by AM0PR07MB4244.eurprd07.prod.outlook.com (52.133.56.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.7; Tue, 7 Jan 2020 16:53:31 +0000
Received: from AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::28e8:93ab:34a6:c38d]) by AM0PR07MB3987.eurprd07.prod.outlook.com ([fe80::28e8:93ab:34a6:c38d%3]) with mapi id 15.20.2623.008; Tue, 7 Jan 2020 16:53:31 +0000
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Kaustubh Inamdar (kinamdar)" <kinamdar@cisco.com>, "dispatch@ietf.org" <dispatch@ietf.org>
CC: Cullen Jennings <fluffy@iii.ca>, "dispatch-chairs@ietf.org" <dispatch-chairs@ietf.org>
Thread-Topic: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)
Thread-Index: AQHVxXr9H6blfIFbz0iZmgQDEHrzGA==
Date: Tue, 07 Jan 2020 16:53:30 +0000
Message-ID: <B33841C9-362C-4901-B169-405AF1B7288E@ericsson.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1e.0.191013
authentication-results: spf=none (sender IP is ) smtp.mailfrom=christer.holmberg@ericsson.com;
x-originating-ip: [89.166.49.243]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: abdf256c-9731-4fa9-4ee0-08d793922044
x-ms-traffictypediagnostic: AM0PR07MB4244:
x-microsoft-antispam-prvs: <AM0PR07MB4244807B5D6C51FFEE94709A933F0@AM0PR07MB4244.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 027578BB13
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(39860400002)(366004)(199004)(189003)(26005)(316002)(86362001)(6506007)(110136005)(53546011)(8936002)(66476007)(66556008)(54906003)(6486002)(6512007)(64756008)(2616005)(66446008)(33656002)(66946007)(8676002)(71200400001)(4326008)(2906002)(44832011)(76116006)(36756003)(5660300002)(478600001)(186003)(81156014)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR07MB4244; H:AM0PR07MB3987.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: z7ni8Ph8XXehHBYbRzQTBSaEu8qZirfrx12j5pUuuXRUOwD8m15qaFVE27slntuBBBHKLxlObzfnG2/Nfk5ND0i4r/IMKuKHZDZvmb7TDSSWs07kdStfrdxGZZkKsHvVuk5CfRSLBQzB8HKlseN5wSnFHgUiIuiPubINfILBBQoI/Te+4kLau6Selm3wJABFz26hOm+GoaR0z29QsZQfkEKD08l7+P/ufiMQw45YTCbMrT/O5oXSiu4acGl00J27+kg0j8Im53oz+bR+rYBxsWpBXF1wVLphxrsCVg/S+OT9h+MbDZk8q47cxsGCv4sFQk2IFBcccVECBFUpUUHTCFVKyjjTzJJES8Y/IhAW0Wzyxm34nOaT/RZs8yf7aPPdoXfgRuareSWq9MJ0XwSYTxIBWshq2DjSBubQVnj9QQ16R7QdtPFBoJ0IBwXOU5SRpS6mAz0aXxbevImtHDxXAMqmQG6bEO0LtIAup2HGnht32N+eTTEIZ0MBL2LRZbYSUiQSYRwxSAJZX1Ew4Vgywg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_B33841C9362C4901B169405AF1B7288Eericssoncom_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: abdf256c-9731-4fa9-4ee0-08d793922044
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 16:53:30.9981 (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: DArhJrd2OtB2D0G+sIkPET9rWy/yXJiuj3l7q744cj50i3ejVoH6xgUdcpB3UL1prP0LekkZJF0W8V7r1algxOm5EPzehaawMOsMrA/+BFU=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4244
Archived-At: <https://mailarchive.ietf.org/arch/msg/dispatch/ANOO_XYOqVn-wbQhG6wDZw4O9FA>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 07 Jan 2020 16:53:44 -0000

Hi,

The suggested charter say that the scope includes defining a capability transport mechanism, but it also says that defining SIP extensions is outside the scope.

What is the reason for excluding possible SIP extensions in the scope? I do know that the there is a suggestion of using HTTP, but I don’t think that decision shall be made in the charter.

Regards,

Christer

From: dispatch <dispatch-bounces@ietf.org> on behalf of "Kaustubh Inamdar (kinamdar)" <kinamdar@cisco.com>
Date: Monday, 6 January 2020 at 7.17
To: "dispatch@ietf.org" <dispatch@ietf.org>
Cc: Cullen Jennings <fluffy@iii.ca>, "dispatch-chairs@ietf.org" <dispatch-chairs@ietf.org>
Subject: Re: [dispatch] PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

Slight modification to the proposed charter…


PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)





The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks is increasing at a rapid pace. Consequently, direct IP peering between enterprise and service provider networks is quickly replacing traditional methods of interconnection between enterprise and service provider networks.

Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often not clear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks resulting in a large number of support cases being opened with enterprise equipment manufacturers and SIP service providers. Subsequently, deployment times for SIP trunking between enterprise and service provider networks increase significantly.

This work would define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, provides the enterprise network with sufficient information to setup SIP trunking with the SIP service provider. Such a capability set would not only result in SIP trunking deployment times being drastically scaled down, but also would result in a significant decrease in interoperability issues between enterprise and service provider network. Additionally, operational costs for service providers and enterprise equipment manufactures would likely decrease as a result of fewer support cases.



The scope of activity includes:



·         Define a robust capability set which encapsulates sufficient information to ensure smooth IP peering between enterprise and service provider SIP networks.

·         Define a data model for the capability set.

·         Extensibility of the data model to allow proprietary parameters to be encoded.

·         A transport mechanism using which the capability set is communicated from the service provider network to the enterprise network.

This working group will not:

·         Define any extensions to SIP.

·         Provide a workflow/mechanism that allows service providers to directly configure devices in the enterprise network.



The group will produce



·         Requirements, Use Cases and Architecture draft.

·         Specification for SIP Auto Peer.



This workgroup will co-ordinate with the SIP Core workgroup and the SIPConnect efforts carried out by the SIP Forum.



Milestones:



<Date TBD> Send architecture draft to IESG

<Date TBD> Send protocol specification draft to IESG


Thanks,
Kaustubh


From: Kaustubh Inamdar <kinamdar@cisco.com>
Date: Monday, 6 January 2020 at 07:12
To: "dispatch@ietf.org" <dispatch@ietf.org>
Cc: "dispatch-chairs@ietf.org" <dispatch-chairs@ietf.org>, Cullen Jennings <fluffy@iii.ca>
Subject: PROPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)

All,
Following the presentation of SIP Auto Peer at IETF 106, Singapore (https://tools.ietf.org/html/draft-kinamdar-dispatch-sip-auto-peer-01) , there was consensus to form a mini workgroup to take this effort forward. To that end, we are looking to build consensus on a charter. The prosed charter can be found below. Comments, reviews, suggestions are welcome.


PRPOSED CHARTER FOR ASAP (Automatic SIP trunking And Peering)



The deployment of a Session Initiation Protocol (SIP)-based infrastructure in enterprise and service provider communication networks is increasing at a rapid pace. Consequently, direct IP peering between enterprise and service provider networks is quickly replacing traditional methods of interconnection between enterprise and service provider networks.

Currently published standards provide a strong foundation over which direct IP peering can be realized. However, given the sheer number of these standards, it is often not clear which behavioural subsets, extensions to baseline protocols and operating principles ought to be configured by the enterprise network administrator to ensure successful peering with a SIP service provider network. This lack of context often leads to interoperability issues between enterprise and service provider SIP networks resulting in a large number of support cases being opened with enterprise equipment manufacturers and SIP service providers. Subsequently, deployment times for SIP trunking between enterprise and service provider networks increase significantly.

This work would define a descriptive capability set, which is populated by a SIP service provider, and which, when communicated to an enterprise network, provides the enterprise network with sufficient information to setup SIP trunking with the SIP service provider. Such a capability set would not only result in SIP trunking deployment times being drastically scaled down, but also would result in a significant decrease in interoperability issues between enterprise and service provider network. Additionally, operational costs for service providers and enterprise equipment manufactures would likely decrease as a result of fewer support cases.



The scope of activity includes:



  *   Define a robust capability set which encapsulates sufficient information to ensure smooth IP peering between enterprise and service provider SIP networks.
  *   Define a data model for the capability set.
  *   Extensibility of the data model to allow proprietary parameters to be encoded.
  *   A transport mechanism using which the capability set is communicated from the service provider network to the enterprise network.

This working group will not:

  *   Define any extensions to SIP.
  *   Provide a workflow/mechanism that allows service providers to directly configure devices in the enterprise network.



The group will produce



  *   Requirements, Use Cases and Architecture draft.
  *   Specification for SIP Auto Peer.



Milestones:



<Date TBD> Send architecture draft to IESG

<Date TBD> Send protocol specification draft to IESG

Thanks,
Kaustubh