<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style>
<!--
@font-face
        {font-family:Calibri}
@font-face
        {font-family:Consolas}
@font-face
        {font-family:Tahoma}
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif"}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:Consolas}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:8.0pt;
        font-family:"Tahoma","sans-serif"}
span.EmailStyle17
        {font-family:"Calibri","sans-serif";
        color:#1F497D}
span.BalloonTextChar
        {font-family:"Tahoma","sans-serif"}
span.PlainTextChar
        {font-family:Consolas}
.MsoChpDefault
        {font-family:"Calibri","sans-serif"}
@page WordSection1
        {margin:72.0pt 72.0pt 72.0pt 72.0pt}
div.WordSection1
        {}
-->
</style>
</head>
<body lang="EN-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText">Hi All</p>
<p class="MsoPlainText"> </p>
<p class="MsoPlainText">We’re currently attempting to integrate GenieACS into our router provisioning process via the REST API, and testing with the GenieACS-GUI. All seems to be great except for a stumbling block we’ve encountered which is the organisation
 of the PortMapping object and how to cleanly use them in a Preset.</p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">As it currently stands, it's quite often we will have per-CPE configurations that include port forwarding based on the client's requests. We have managed to preset PortMappings, however we had to create an object for each
 PortMapping, each with their own unique values for the indiviual port forwards. My concern with creating objects for each PortForward is the added complexity, naming and management of them via the API.</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">My question to you all, is how are you currently handling presetting almost-unique objects to a device? Do we have to create an object for each individual port forward, or is it possible to add and subsequently set the
 parameters just with the presets? </span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">Here’s an example of a PortMapping:</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.ExternalPort 0 
</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.RemoteHost 
</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.PortMappingEnabled false 
</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.PortMappingProtocol TCP 
</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.ExternalPortEndRange 0 
</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.PortMappingLeaseDuration 0</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.InternalClient 
</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.InternalPort 0 
</span></p>
<p class="MsoPlainText"><span style="">InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANPPPConnection.1.PortMapping.1.PortMappingDescription</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">You can probably imagine, it might get messy if an object is needed for each different mapping. Apologies if I've missed something completely obvious!</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">Thanks in advance.</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">Regards</span></p>
<p class="MsoPlainText"><span style=""> </span></p>
<p class="MsoPlainText"><span style="">Harry Foster</span></p>
<p class="MsoNormal"><span lang="EN-US" style="color:#365F91"> </span></p>
</div>
<br>
This email was sent on behalf of Spitfire Network Services Limited. This e-mail is strictly confidential and intended solely for the addressee(s). It may contain personal and confidential information and as such may be protected by the Data Protection Acts
 1984 and 1998. If you are not the intended recipient of this email you must: (i) Not disclose, copy or distribute its contents to any other person nor use its contents in any way or you may be acting unlawfully; (ii) Contact Spitfire immediately on +44 (0)
 20 7501 3000 quoting the name of the sender and the addressee then delete it from your system. Any views or opinions expressed within this email are those of the author and do not necessarily represent those of Spitfire Network Services Ltd. Email may be monitored
 for security purposes. You should scan attachments (if any) for viruses. <br>
We may record store and use any telephone calls with you in order to check any instructions given to us, to maintain our business records, for training purposes and to improve the quality of our services.
<br>
<br>
Spitfire Network Services Ltd. Registered No. 2657590. Registered Office: 239 Regents Park Road, London N3 3LF
</body>
</html>