<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body><div style="font-family:Helvetica,Arial;font-size:13px">Nice theory, David.</div><div style="font-family:Helvetica,Arial;font-size:13px"><br></div><div style="font-family:Helvetica,Arial;font-size:13px">When I saw Brian’s message, I wondered if a NENA nerd thought something like, “Hey, isn’t it cool that a PHB of AF12 has a DSCP value of 12 in decimal—that ought to make it easy for us to remember! …’cause I sure do like the number 12. It is the smallest ‘abundant' number, after all...” ;)</div> <div><span class="Apple-tab-span" style="white-space:pre"> </span>{perhaps my wonderings reveal something about me...}</div><div><br></div><div>~Brian~</div> <div class="gmail_signature"></div> <br><p class="airmail_on">On March 18, 2020 at 11:35:47 AM, Hiers, David (<a href="mailto:david.hiers@cdk.com">david.hiers@cdk.com</a>) wrote:</p> <blockquote type="cite" class="clean_bq"><span><div><div></div><div>No argument there. I have no idea what they were smoking, and probably don't want to try it!
<br>
<br>I have a feeling that they're using the term 'facility' as an abstraction to represent the part of the network that is opaque with respect to what is described in the standard. They may be trying to express the idea that they don't care if there are other fibers in the trench, other lambdas on the fiber, or other traffic on a 5ESS in the middle of some telco. Without some sharing being permitted, the requirement to be 'private' could be read very expansively.
<br>
<br>I'm totally guessing here... For all I know, the guy that wrote it wanted to be sure that nobody's auto-qos would work, thus guaranteeing more billable hours for his brother-in-law.
<br>
<br>David
<br>
<br>
<br>-----Original Message-----
<br>From: Brian Knight [mailto:<a href="mailto:ml@knight-networks.com">ml@knight-networks.com</a>]
<br>Sent: Wednesday, March 18, 2020 8:04 AM
<br>To: Hiers, David <<a href="mailto:David.Hiers@cdk.com">David.Hiers@cdk.com</a>>
<br>Cc: Voiceops <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>>
<br>Subject: Re: [VoiceOps] NENA SIP Marking Specifications
<br>
<br>Hi David, thanks for the reply.
<br>
<br>Unfortunately, a "private" network doesn't necessarily mean dedicated infrastructure. Their documentation explicitly states that "ESInets may be constructed from a mix of dedicated and shared facilities." So it seems like it should be in NENA's best interest to follow the de facto standard to ensure operation over shared facilities.
<br>
<br>Thanks,
<br>
<br>-Brian
<br>
<br>
<br>On 2020-03-17 17:45, Hiers, David wrote:
<br>> Hi Brian,
<br>>
<br>> That standard applies to " Emergency Services IP Networks", which, by
<br>> definition, are entirely private. They control their entire
<br>> universe; there is simply no reason for NENA to care about default
<br>> behavior of any device or network.
<br>>
<br>> As to why they picked these values... I have no idea, but they
<br>> defined 'most networks' as out of scope, so why not?
<br>>
<br>> David
<br>>
<br>>
<br>> -----Original Message-----
<br>> From: VoiceOps [mailto:<a href="mailto:voiceops-bounces@voiceops.org">voiceops-bounces@voiceops.org</a>] On Behalf Of
<br>> Brian Knight
<br>> Sent: Tuesday, March 17, 2020 2:22 PM
<br>> To: Voiceops <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>>
<br>> Subject: [VoiceOps] NENA SIP Marking Specifications
<br>>
<br>> I have been working to deploy a new private WAN for a customer that
<br>> services E911 emergency calls delivered over VoIP. While working on
<br>> this, I learned that their DSCP markings for SIP control traffic are
<br>> AF12, not AF31 or CS3 which is what I typically see from our other
<br>> enterprise customers. Media is still marked EF.
<br>>
<br>> These markings appear to have been standardized by a body called NENA,
<br>> National Emergency Number Association. Googling 'NENA SIP "AF12"'
<br>> returns the relevant PDFs. Below is a sample from their standards
<br>> guide.
<br>>
<br>> DSCP | Use | PHB
<br>> -----+----------------------------------+--------
<br>> 0 | Routine Traffic | Default
<br>> 1 | 9-1-1 Signaling | AF12
<br>> 2 | 9-1-1 Text Media | AF12
<br>> 3 | 9-1-1 Audio Media | EF
<br>> 4 | 9-1-1 Video Media | AF11
<br>> 5 | 9-1-1 Non-human-initiated Call | AF21
<br>> 6 | Intra ESInet* Events | AF21
<br>> 7 | Intra ESInet Other 9-1-1 Traffic | AF22
<br>>
<br>> (* Emergency Services IP Network)
<br>>
<br>> Does anyone know the reasoning behind specifying SIP as AF12 instead
<br>> of AF31? While developing these standards, was NENA aware that AF12
<br>> tends to be prioritized lower than AF31 on most networks?
<br>>
<br>> Just trying to get some background on the decision.
<br>>
<br>> Thanks,
<br>>
<br>> -Brian
<br>> _______________________________________________
<br>> VoiceOps mailing list
<br>> <a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<br>> <a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
<br>>
<br>> ----------------------------------------------------------------------
<br>> This message and any attachments are intended only for the use of the
<br>> addressee and may contain information that is privileged and
<br>> confidential. If the reader of the message is not the intended
<br>> recipient or an authorized representative of the intended recipient,
<br>> you are hereby notified that any dissemination of this communication
<br>> is strictly prohibited. If you have received this communication in
<br>> error, notify the sender immediately by return email and delete the
<br>> message and any attachments from your system.
<br>
<br>----------------------------------------------------------------------
<br>This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
<br>_______________________________________________
<br>VoiceOps mailing list
<br><a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<br><a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
<br></div></div></span></blockquote></body></html>