[VoiceOps] NENA SIP Marking Specifications

[Brian Tate (Eng)]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20200318/771720a4/attachment-0001.htm>