I have been working to deploy a new private WAN for a customer that services E911 emergency calls delivered over VoIP. While working on this, I learned that their DSCP markings for SIP control traffic are AF12, not AF31 or CS3 which is what I typically see from our other enterprise customers. Media is still marked EF. These markings appear to have been standardized by a body called NENA, National Emergency Number Association. Googling 'NENA SIP "AF12"' returns the relevant PDFs. Below is a sample from their standards guide. DSCP | Use | PHB -----+----------------------------------+-------- 0 | Routine Traffic | Default 1 | 9-1-1 Signaling | AF12 2 | 9-1-1 Text Media | AF12 3 | 9-1-1 Audio Media | EF 4 | 9-1-1 Video Media | AF11 5 | 9-1-1 Non-human-initiated Call | AF21 6 | Intra ESInet* Events | AF21 7 | Intra ESInet Other 9-1-1 Traffic | AF22 (* Emergency Services IP Network) Does anyone know the reasoning behind specifying SIP as AF12 instead of AF31? While developing these standards, was NENA aware that AF12 tends to be prioritized lower than AF31 on most networks? Just trying to get some background on the decision. Thanks, -Brian
Hi Brian, That standard applies to " Emergency Services IP Networks", which, by definition, are entirely private. They control their entire universe; there is simply no reason for NENA to care about default behavior of any device or network. As to why they picked these values... I have no idea, but they defined 'most networks' as out of scope, so why not? David -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Brian Knight Sent: Tuesday, March 17, 2020 2:22 PM To: Voiceops <voiceops at voiceops.org> Subject: [VoiceOps] NENA SIP Marking Specifications I have been working to deploy a new private WAN for a customer that services E911 emergency calls delivered over VoIP. While working on this, I learned that their DSCP markings for SIP control traffic are AF12, not AF31 or CS3 which is what I typically see from our other enterprise customers. Media is still marked EF. These markings appear to have been standardized by a body called NENA, National Emergency Number Association. Googling 'NENA SIP "AF12"' returns the relevant PDFs. Below is a sample from their standards guide. DSCP | Use | PHB -----+----------------------------------+-------- 0 | Routine Traffic | Default 1 | 9-1-1 Signaling | AF12 2 | 9-1-1 Text Media | AF12 3 | 9-1-1 Audio Media | EF 4 | 9-1-1 Video Media | AF11 5 | 9-1-1 Non-human-initiated Call | AF21 6 | Intra ESInet* Events | AF21 7 | Intra ESInet Other 9-1-1 Traffic | AF22 (* Emergency Services IP Network) Does anyone know the reasoning behind specifying SIP as AF12 instead of AF31? While developing these standards, was NENA aware that AF12 tends to be prioritized lower than AF31 on most networks? Just trying to get some background on the decision. Thanks, -Brian _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops ---------------------------------------------------------------------- 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.
Hi David, thanks for the reply. 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. Thanks, -Brian On 2020-03-17 17:45, Hiers, David wrote:
Hi Brian,
That standard applies to " Emergency Services IP Networks", which, by definition, are entirely private. They control their entire universe; there is simply no reason for NENA to care about default behavior of any device or network.
As to why they picked these values... I have no idea, but they defined 'most networks' as out of scope, so why not?
David
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Brian Knight Sent: Tuesday, March 17, 2020 2:22 PM To: Voiceops <voiceops at voiceops.org> Subject: [VoiceOps] NENA SIP Marking Specifications
I have been working to deploy a new private WAN for a customer that services E911 emergency calls delivered over VoIP. While working on this, I learned that their DSCP markings for SIP control traffic are AF12, not AF31 or CS3 which is what I typically see from our other enterprise customers. Media is still marked EF.
These markings appear to have been standardized by a body called NENA, National Emergency Number Association. Googling 'NENA SIP "AF12"' returns the relevant PDFs. Below is a sample from their standards guide.
DSCP | Use | PHB -----+----------------------------------+-------- 0 | Routine Traffic | Default 1 | 9-1-1 Signaling | AF12 2 | 9-1-1 Text Media | AF12 3 | 9-1-1 Audio Media | EF 4 | 9-1-1 Video Media | AF11 5 | 9-1-1 Non-human-initiated Call | AF21 6 | Intra ESInet* Events | AF21 7 | Intra ESInet Other 9-1-1 Traffic | AF22
(* Emergency Services IP Network)
Does anyone know the reasoning behind specifying SIP as AF12 instead of AF31? While developing these standards, was NENA aware that AF12 tends to be prioritized lower than AF31 on most networks?
Just trying to get some background on the decision.
Thanks,
-Brian _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
---------------------------------------------------------------------- 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.
No argument there. I have no idea what they were smoking, and probably don't want to try it! 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. 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. David -----Original Message----- From: Brian Knight [mailto:ml at knight-networks.com] Sent: Wednesday, March 18, 2020 8:04 AM To: Hiers, David <David.Hiers at cdk.com> Cc: Voiceops <voiceops at voiceops.org> Subject: Re: [VoiceOps] NENA SIP Marking Specifications Hi David, thanks for the reply. 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. Thanks, -Brian On 2020-03-17 17:45, Hiers, David wrote:
Hi Brian,
That standard applies to " Emergency Services IP Networks", which, by definition, are entirely private. They control their entire universe; there is simply no reason for NENA to care about default behavior of any device or network.
As to why they picked these values... I have no idea, but they defined 'most networks' as out of scope, so why not?
David
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Brian Knight Sent: Tuesday, March 17, 2020 2:22 PM To: Voiceops <voiceops at voiceops.org> Subject: [VoiceOps] NENA SIP Marking Specifications
I have been working to deploy a new private WAN for a customer that services E911 emergency calls delivered over VoIP. While working on this, I learned that their DSCP markings for SIP control traffic are AF12, not AF31 or CS3 which is what I typically see from our other enterprise customers. Media is still marked EF.
These markings appear to have been standardized by a body called NENA, National Emergency Number Association. Googling 'NENA SIP "AF12"' returns the relevant PDFs. Below is a sample from their standards guide.
DSCP | Use | PHB -----+----------------------------------+-------- 0 | Routine Traffic | Default 1 | 9-1-1 Signaling | AF12 2 | 9-1-1 Text Media | AF12 3 | 9-1-1 Audio Media | EF 4 | 9-1-1 Video Media | AF11 5 | 9-1-1 Non-human-initiated Call | AF21 6 | Intra ESInet* Events | AF21 7 | Intra ESInet Other 9-1-1 Traffic | AF22
(* Emergency Services IP Network)
Does anyone know the reasoning behind specifying SIP as AF12 instead of AF31? While developing these standards, was NENA aware that AF12 tends to be prioritized lower than AF31 on most networks?
Just trying to get some background on the decision.
Thanks,
-Brian _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
---------------------------------------------------------------------- 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.
---------------------------------------------------------------------- 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.
Nice theory, David. 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...? ;) {perhaps my wonderings reveal something about me...} ~Brian~ On March 18, 2020 at 11:35:47 AM, Hiers, David (david.hiers at cdk.com) wrote: No argument there. I have no idea what they were smoking, and probably don't want to try it! 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. 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. David -----Original Message----- From: Brian Knight [mailto:ml at knight-networks.com] Sent: Wednesday, March 18, 2020 8:04 AM To: Hiers, David <David.Hiers at cdk.com> Cc: Voiceops <voiceops at voiceops.org> Subject: Re: [VoiceOps] NENA SIP Marking Specifications Hi David, thanks for the reply. 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. Thanks, -Brian On 2020-03-17 17:45, Hiers, David wrote:
Hi Brian,
That standard applies to " Emergency Services IP Networks", which, by definition, are entirely private. They control their entire universe; there is simply no reason for NENA to care about default behavior of any device or network.
As to why they picked these values... I have no idea, but they defined 'most networks' as out of scope, so why not?
David
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Brian Knight Sent: Tuesday, March 17, 2020 2:22 PM To: Voiceops <voiceops at voiceops.org> Subject: [VoiceOps] NENA SIP Marking Specifications
I have been working to deploy a new private WAN for a customer that services E911 emergency calls delivered over VoIP. While working on this, I learned that their DSCP markings for SIP control traffic are AF12, not AF31 or CS3 which is what I typically see from our other enterprise customers. Media is still marked EF.
These markings appear to have been standardized by a body called NENA, National Emergency Number Association. Googling 'NENA SIP "AF12"' returns the relevant PDFs. Below is a sample from their standards guide.
DSCP | Use | PHB -----+----------------------------------+-------- 0 | Routine Traffic | Default 1 | 9-1-1 Signaling | AF12 2 | 9-1-1 Text Media | AF12 3 | 9-1-1 Audio Media | EF 4 | 9-1-1 Video Media | AF11 5 | 9-1-1 Non-human-initiated Call | AF21 6 | Intra ESInet* Events | AF21 7 | Intra ESInet Other 9-1-1 Traffic | AF22
(* Emergency Services IP Network)
Does anyone know the reasoning behind specifying SIP as AF12 instead of AF31? While developing these standards, was NENA aware that AF12 tends to be prioritized lower than AF31 on most networks?
Just trying to get some background on the decision.
Thanks,
-Brian _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
---------------------------------------------------------------------- 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.
---------------------------------------------------------------------- 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. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Twelve is special. It is also the largest one syllable number. Just sayin. (BTW: I had to look up what an abundant number was.) From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Brian Tate (Eng) Sent: Wednesday, March 18, 2020 9:42 AM To: Hiers, David <David.Hiers at cdk.com>; Brian Knight <ml at knight-networks.com> Cc: Voiceops <voiceops at voiceops.org> Subject: Re: [VoiceOps] NENA SIP Marking Specifications Nice theory, David. 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...? ;) {perhaps my wonderings reveal something about me...} ~Brian~ On March 18, 2020 at 11:35:47 AM, Hiers, David (david.hiers at cdk.com<mailto:david.hiers at cdk.com>) wrote: No argument there. I have no idea what they were smoking, and probably don't want to try it! 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. 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. David -----Original Message----- From: Brian Knight [mailto:ml at knight-networks.com<mailto:ml at knight-networks.com>] Sent: Wednesday, March 18, 2020 8:04 AM To: Hiers, David <David.Hiers at cdk.com<mailto:David.Hiers at cdk.com>> Cc: Voiceops <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> Subject: Re: [VoiceOps] NENA SIP Marking Specifications Hi David, thanks for the reply. 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. Thanks, -Brian On 2020-03-17 17:45, Hiers, David wrote:
Hi Brian,
That standard applies to " Emergency Services IP Networks", which, by definition, are entirely private. They control their entire universe; there is simply no reason for NENA to care about default behavior of any device or network.
As to why they picked these values... I have no idea, but they defined 'most networks' as out of scope, so why not?
David
-----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of Brian Knight Sent: Tuesday, March 17, 2020 2:22 PM To: Voiceops <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> Subject: [VoiceOps] NENA SIP Marking Specifications
I have been working to deploy a new private WAN for a customer that services E911 emergency calls delivered over VoIP. While working on this, I learned that their DSCP markings for SIP control traffic are AF12, not AF31 or CS3 which is what I typically see from our other enterprise customers. Media is still marked EF.
These markings appear to have been standardized by a body called NENA, National Emergency Number Association. Googling 'NENA SIP "AF12"' returns the relevant PDFs. Below is a sample from their standards guide.
DSCP | Use | PHB -----+----------------------------------+-------- 0 | Routine Traffic | Default 1 | 9-1-1 Signaling | AF12 2 | 9-1-1 Text Media | AF12 3 | 9-1-1 Audio Media | EF 4 | 9-1-1 Video Media | AF11 5 | 9-1-1 Non-human-initiated Call | AF21 6 | Intra ESInet* Events | AF21 7 | Intra ESInet Other 9-1-1 Traffic | AF22
(* Emergency Services IP Network)
Does anyone know the reasoning behind specifying SIP as AF12 instead of AF31? While developing these standards, was NENA aware that AF12 tends to be prioritized lower than AF31 on most networks?
Just trying to get some background on the decision.
Thanks,
-Brian _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_voiceops&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=_Y9yOOWR4hwaXwmFi1u5SqCk-H991m_snhHFv1VWB7c&s=LlZqHLBUZexwpcsPP8d8ToxC-LboCFvfYvpwuGsNpvY&e=>
---------------------------------------------------------------------- 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.
---------------------------------------------------------------------- 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. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailman_listinfo_voiceops&d=DwMFaQ&c=N13-TaG7c-EYAiUNohBk74oLRjUiBTwVm-KSnr4bPSc&r=VcRLyVxkyGds34uxiPM944HQvaWq-nynyZXfNpSfhOs&m=_Y9yOOWR4hwaXwmFi1u5SqCk-H991m_snhHFv1VWB7c&s=LlZqHLBUZexwpcsPP8d8ToxC-LboCFvfYvpwuGsNpvY&e=>
participants (4)
-
briantate.engineer＠gmail.com -
David.Hiers＠cdk.com -
David.Zilk＠cdk.com -
ml＠knight-networks.com