DISA Interoperability Requirements - Chat.xlsx

REV 07102026_CHAT

(DRAFT) SIP-SIMPLE Chat ↔ DoW Microsoft Teams Chat interoperability Requirements (DRAFT)

(REV 07152026)

Microsoft Teams Chat is the DoW standard for text/instant messaging (ref: DoD CIO Policy, 27 Sep 2023) . The requirements listed below evaluate the interoperability of a commercial Chat standard, SIP-SIMPLE, and Microsoft Teams as implemented in DoW. The requirements below are focused on interoperability to the largest extent possible. Any associated cybersecurity requirements are being covered separately in Security Technical Implementation Guides (STIGs).

SIP-SIMPLE Chat and DoW Microsoft Teams are not natively interoperable as peer chat systems. The reason for Teams and SIP not being interoperable by default is their fundamental architecture difference. Wheras SIP uses its default suite of message types to convey inofrmation similar to standard network communication. Microsoft teams uses HTTPS Rest APIs, which are not natively interchangeable without a translator in the middle. SIP-SIMPLE is a SIP-based Instant Messaging (IM) and presence standard based on a suite of SIP protocols. Microsoft Teams Chat is exposed through through its own Application Program Interface (API), Microsoft Graph API (https://learn.microsoft.com/en-us/graph/api/resources/teams-api-overview?view=graph-rest-1.0). If required to interoperae a SIP-SIMPLE Chat with DoW Teams, the only practical alternative is to build a SIP-SIMPLE-to-Teams gateway that translates SIP-SIMPLE signaling and presence into the Microsoft API calls [Microsoft Graph is the API), and inherits the Teams capabilities. The requirements listed below are aimed to test the interoperability of the gateway required to interoperate SIP-SIMPLE to DoW MS Teams. It assumes high availability best practices; otherwise, the application is not operationally serviceable. Interoperability requirements are often repeated to reflect the multiple tests required to fully test each requirement. Read each requirement row left to right, using the notes to supplement your understanding. Requirements that seem more appropriate for a Security Technical Implementation Guide (STIG) are included in the worksheet labeled "STIG CANDIDATES."

https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan https://learn.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/cloud-overview https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0 20 Use a supported Teams DoW interop architecture High Unknown The gateway shall expose only the SIP-SIMPLE capabilities that it can actually translate to Teams DoW. Prevents peers from negotiating capabilities such as direct Teams SIP messaging, Teams shared-channel bot support, or MSRP file transfer when the Teams side cannot support them. Review SIP OPTIONS/feature advertisement and Teams app manifest/configuration. Attempt an unsupported mode, such as direct Teams SIP MESSAGE or DoW incoming webhook delivery. Unsupported features are absent from advertised capabilities or rejected with a deterministic SIP/API error. Tolerance: zero silent acceptance of unsupported modes. Document the supported-mode matrix in the gateway release notes. https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/cloud-overview https://learn.microsoft.com/en-us/microsoftteams/devices/sip-gateway-plan https://learn.microsoft.com/en-us/microsoftteams/microsoft-teams-online-call-flows 30 Use Microsoft 365 DoW cloud endpoints and tenant isolation High Unknown For all Teams-side API traffic, the gateway shall use DoW national cloud identity and Graph endpoints, including login.microsoftonline.us and https://DoW-graph.microsoft.us, with tokens issued for the DoW resource. Prevents messages, identities, presence, or subscriptions from crossing into the commercial Graph cloud or failing due to wrong-token audience/issuer. Acquire a token for the DoW tenant, call /me or a test Teams messaging endpoint through https://DoW-graph.microsoft.us, and capture gateway outbound DNS/SNI/HTTP logs. The token issuer is the US Government authority and the audience/resource is the DoW Graph endpoint. 100% of Graph calls in the test use DoW-graph.microsoft.us. Authorized calls return expected 200/201/202 responses. Use tenant-specific admin-approved test accounts only. https://learn.microsoft.com/en-us/graph/deployments https://learn.microsoft.com/en-us/graph/teamwork-national-cloud-differences

https://learn.microsoft.com/en-us/microsoftteams/platform/resources/bot-v3/bots-overview https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages

https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-ip-web-service?view=o365-worldwide https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages

https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 https://datatracker.ietf.org/doc/html/rfc3862 https://www.rfc-editor.org/info/rfc3428/ 100 Map SIP identities to Teams identities deterministically High Unknown The gateway shall fail unknown or ambiguous recipients predictably and without creating unintended Teams chats. Prevents accidental disclosure and confusing phantom chats when SIP address resolution is incomplete. Send SIP MESSAGE requests to an unmapped SIP URI and to a SIP URI deliberately mapped to two possible Teams users. Unknown recipients receive a deterministic failure such as SIP 404/480 or a gateway error notification; ambiguous mappings fail with an administrative error. Tolerance: zero Teams chats created for invalid/ambiguous recipients. Use program-approved SIP response mapping. https://learn.microsoft.com/en-us/graph/api/resources/chat?view=graph-rest-1.0 https://www.rfc-editor.org/info/rfc3428/ 110 Authenticate and authorize Teams operations with supported permissions High Unknown The gateway Teams-side sends, receives, presence reads, and app installations shall use supported Microsoft Entra OAuth flows and least-privileged permissions for DoW. Standard Graph chatMessage posting shall use supported delegated permissions for interactive sends; application permission use shall not be misused for live user messaging outside documented migration/import modes. Avoids failures caused by unavailable permissions in DoW and avoids messages that appear from the wrong actor. Grant only the documented permissions needed for one selected path: Teams bot/RSC receive, Graph delegated send, Graph change notifications, and/or presence read. Send and receive test messages. Authorized operations succeed; token claims match the selected DoW tenant and only approved scopes/roles are present. Tolerance: 100% success for approved operations; no extra Graph app roles beyond the approved permission set. Record the exact consent screen or admin-consent grant as test evidence. https://learn.microsoft.com/en-us/graph/deployments https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0 https://learn.microsoft.com/en-us/graph/teamwork-national-cloud-differences https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/channel-messages-for-bots-and-agents 120 Authenticate and authorize Teams operations with supported permissions High Unknown The gateway shall handle expired, wrong-cloud, missing-scope, or denied-consent tokens without losing SIP messages. Maintains interop availability and clear error reporting during authorization faults. Use an expired token, a token issued for the worldwide Graph resource, and a token missing ChatMessage.Send or required bot/RSC permission. Attempt message delivery. Gateway returns or queues an actionable failure; no message is posted under a fallback identity. Tolerance: 0 unauthorized deliveries; all failures logged with HTTP status, tenant ID, and correlation ID. Do not include sensitive token material in logs. https://learn.microsoft.com/en-us/graph/deployments https://learn.microsoft.com/en-us/graph/throttling 130 Advertise and negotiate SIP-SIMPLE capabilities accurately High Unknown The SIP-facing side of the gateway shall support SIP capability discovery and shall advertise only the methods, event packages, transports, MIME types, and extensions it can translate to Teams DoW. Capability mismatch is a common interop failure: peers may attempt MSRP, message/cpim, PIDF, IMDN, or isComposing behavior that the gateway cannot bridge. Send SIP OPTIONS and supported SUBSCRIBE/MESSAGE probes from the commercial system. Inspect Allow, Supported, Accept, Event, and Contact/SIPS transport behavior. The gateway advertises exactly the supported interop set. Unsupported content types or methods return 415, 420, 488, or 501 as appropriate. Tolerance: zero advertised capabilities that fail in subsequent functional tests. Map response code specifics to the selected SIP stack profile. https://www.rfc-editor.org/info/rfc3428/ https://www.rfc-editor.org/info/rfc3856/ https://www.rfc-editor.org/info/rfc3863/ https://datatracker.ietf.org/doc/html/rfc3862 https://datatracker.ietf.org/doc/rfc3994/ https://datatracker.ietf.org/doc/html/rfc5438 https://www.rfc-editor.org/info/rfc4975/ 140 Advertise and negotiate SIP-SIMPLE capabilities accurately High Unknown The gateway shall be explicit about unsupported Teams-side features such as read receipts in large Teams chats. Prevents feature assumptions from one side causing user-visible inconsistency on the other side. Create a feature matrix for the tested topology and try each declared unsupported feature from the SIP side and Teams side. Unsupported features are rejected or degraded according to the matrix, never silently represented as successful. Tolerance: zero silent drops for unsupported features. Keep this matrix under configuration control. https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams https://learn.microsoft.com/en-us/microsoftteams/platform/concepts/cloud-overview 150 Bridge SIP MESSAGE page-mode messages High Unknown The gateway shall accept and generate RFC 3428 SIP MESSAGE requests for page-mode instant messaging and map them to Teams chatMessage or bot Activity messages. Provides the base text-chat interop path for SIMPLE systems that use SIP MESSAGE rather than session-mode MSRP. From a SIP client, send MESSAGE requests with Content-Type text/plain and message/cpim to a mapped Teams user/channel. Payloads: ASCII, UTF-8 emoji, line breaks, and URLs. SIP sender receives success only after the gateway has accepted/queued the message for Teams. Teams recipient sees the message body with no semantic loss. Tolerance: p95 delivery <=5 s without throttling; 0 character corruption; 0 silent truncations. Latency target is an interop acceptance target, not a Microsoft SLA. https://www.rfc-editor.org/info/rfc3428/ https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0 https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages 160 Bridge SIP MESSAGE page-mode messages High Unknown The gateway shall generate valid SIP MESSAGE requests for Teams-originated text messages and include routeable To/From identities. Allows Teams-originated conversations to continue on the SIP-SIMPLE system with correct routing context. From Teams, send a message in each claimed topology. Capture the SIP MESSAGE emitted by the gateway to the SIP system. SIP MESSAGE is syntactically valid; To, From, Call-ID/Message-ID/correlation metadata, Content-Type, and body are correct. SIP recipient renders text correctly. Tolerance: 0 protocol parse errors across 50 messages. Include a re-test after Teams edit/reaction events to ensure they do not create malformed SIP MESSAGE bodies. https://www.rfc-editor.org/info/rfc3428/ https://datatracker.ietf.org/doc/html/rfc3862 https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 170 Handle MSRP/session-mode messaging explicitly Medium Unknown If the commercial SIP-SIMPLE system uses MSRP negotiated by SIP/SDP, the gateway shall either implement MSRP session termination and translate MSRP SEND chunks to Teams messages or reject session-mode messaging predictably. Prevents a SIP peer from establishing a chat session that Teams cannot natively terminate. Initiate a SIP INVITE with m=message MSRP from the commercial client. If MSRP is supported, send 10 messages in the session. If unsupported, verify the rejection path. Supported path: all 10 MSRP SEND payloads appear as ordered Teams messages with session/thread context. Unsupported path: gateway rejects with 488/501/declared code before accepting content. Tolerance: 0 partial sessions with silently discarded MSRP payloads. MSRP support shall be declared separately from SIP MESSAGE support. https://www.rfc-editor.org/info/rfc4975/ https://www.rfc-editor.org/info/rfc3428/ https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 180 Capture Teams-originated messages reliably High Unknown The gateway shall use a supported Teams DoW event path, such as bot messages with appropriate scopes/RSC or Microsoft Graph change notifications, to capture Teams-originated messages that shall be forwarded to SIP. Polling-only or @mention-only designs can miss messages and break two-way chat semantics. In a Teams chat/channel where the gateway claims full capture, send messages without @mentioning the bot. Verify notification/event receipt and SIP forwarding. Every in-scope Teams message is captured and forwarded. Tolerance: 0 missed messages in 100-message functional test; p95 event-to-SIP latency <=10 s without throttling. If only @mention capture is supported, the product shall label the scope as @mention-only. https://learn.microsoft.com/en-us/graph/teams-changenotifications-chatmessage https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/channel-messages-for-bots-and-agents https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 190 Capture Teams-originated messages reliably High Unknown The gateway shall renew Graph subscriptions and handle lifecycle notifications so message capture does not expire silently. Expired subscriptions create one-way interop failures that are hard for users to detect. Create a message subscription, force or wait for near-expiration, and send messages before, during, and after renewal. Simulate a 10-minute gateway outage. Subscription renews before expiration; messages during outage are recovered using delta/list catch-up where the selected API supports it. Tolerance: 0 lost messages; duplicate rate 0 after idempotency processing. Subscription expiration intervals and lifecycle requirements shall be recorded in the test log. https://learn.microsoft.com/en-us/graph/teams-changenotifications-chatmessage https://learn.microsoft.com/en-us/graph/throttling 200 Normalize message body formats without semantic loss Medium Unknown The gateway shall transform Teams HTML/plaintext chatMessage bodies and SIP MIME bodies (text/plain, text/html, message/cpim) into the closest safe representation for the receiving system. Ensures readable chat content despite Teams using HTML for some messages and SIP-SIMPLE using MIME/CPIM payloads. Send messages containing bold text, bullets, line breaks, hyperlinks, code-like text, and Teams HTML from both directions. Receiving side preserves text, order, links, and line breaks. Unsupported formatting is downgraded to plain text or safe HTML. Tolerance: 0 lost words; 0 raw unsafe/unsupported tags rendered to SIP users unless explicitly configured. Allowed formatting loss shall be documented by feature. https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0 https://datatracker.ietf.org/doc/html/rfc3862 https://www.rfc-editor.org/info/rfc3428/ 210 Normalize message body formats without semantic loss Medium Unknown The gateway shall preserve Unicode and character-set semantics for multilingual DoW users. Character corruption can make messages operationally unusable or ambiguous. Send test strings with accented characters, CJK, Arabic/Hebrew bidirectional text, emoji, and combining characters in both directions. Received text matches Unicode NFC-normalized source where normalization is configured; no replacement characters appear. Tolerance: 0 code-point loss for supported characters across 25 multilingual samples. Record the chosen Unicode normalization policy. https://www.rfc-editor.org/info/rfc3428/ https://datatracker.ietf.org/doc/html/rfc3862 https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 220 Enforce common message size limits and segmentation rules High Unknown The gateway shall enforce the lowest effective message-size limit across Teams, Graph/Bot path, and SIP transport, and shall segment or reject oversize messages predictably. Prevents truncation, HTTP rejection, SIP fragmentation failures, or user belief that a message was delivered when it was not. Send 1 KB, 20 KB, and 80 KB text messages in each supported direction and topology. All messages at or below the configured safe threshold deliver without truncation. For Teams chat/channel bodies, 80 KB is the recommended engineering ceiling unless the program selects a lower value. Tolerance: 100% delivery for 30 messages at each size under no throttle. Teams documentation calls 100 KB approximate; 80 KB is safer for implementation testing. https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams https://www.rfc-editor.org/info/rfc3428/ https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0 230 Enforce common message size limits and segmentation rules High Unknown The gateway shall not silently truncate oversize messages. Reliable rejection/segmentation is necessary for interoperability when systems have different payload limits. Send 120 KB and 300 KB text payloads from SIP and Teams. Exercise both configured behaviors: segment and reject. Segment mode: segments arrive in order with part numbers and reassembly guidance; reject mode: sender receives a clear failure. Tolerance: 0 silent truncations; 0 out-of-order segments after final delivery. Program may set stricter limits for operational chat usability. https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams https://www.rfc-editor.org/info/rfc3428/ 240 Bridge or explicitly degrade attachments and files Medium Unknown The gateway shall define an attachment policy for Teams file references, SIP MESSAGE bodies, and optional MSRP/file-transfer capabilities. It shall either transfer the file through an approved repository/link model or notify both sides that attachment transfer is unsupported. Teams stores chat/channel files in SharePoint/OneDrive and represents attachments as references, while SIP-SIMPLE page-mode messaging does not provide equivalent Teams file semantics. Send a Teams message with one file attachment, a message with 10 attachments, and a message exceeding the configured attachment limit. Capture SIP-side rendering. Supported transfer: SIP side receives approved link or file-transfer notice with name, size, sender, and correlation ID. Unsupported transfer: SIP side receives an explicit non-delivery notice. Tolerance: 0 attachments silently omitted; 0 unauthorized file URLs exposed beyond policy. Only evaluate interoperability mechanics; content security review is a separate track. https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 https://www.rfc-editor.org/info/rfc4975/ 250 Bridge or explicitly degrade attachments and files Medium Unknown The gateway shall handle SIP-originated binary or HTML attachments according to the same policy. Maintains two-way user expectations and avoids one-direction-only feature asymmetry. Send SIP MESSAGE with multipart MIME and, if supported, MSRP file transfer. Include a small text attachment and an unsupported binary attachment. Teams recipient sees an approved file/link or a clear unsupported-attachment notice. Tolerance: 0 malformed Teams messages; 0 silent attachment loss. If Graph/Bot cannot create the desired Teams file reference, the gateway shall not fake success. https://www.rfc-editor.org/info/rfc3428/ https://www.rfc-editor.org/info/rfc4975/ https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams 260 Translate success, failure, and delivery semantics Medium Unknown The gateway shall map SIP response codes, CPIM/IMDN delivery states, Graph HTTP responses, and Bot Framework responses to consistent success/failure indications for users and logs. Prevents one system from reporting success while the other system rejected, blocked, throttled, or never received the message. Send valid 1:1 and channel messages in both directions. Capture SIP responses, Graph/Bot responses, gateway queue state, and recipient UI. SIP success is returned only after the gateway has accepted durable responsibility or after Teams acceptance, per configured mode. Graph send returns 201 Created where Graph send is used. Tolerance: 0 false success for messages not accepted by gateway/Teams. Define accepted vs delivered vs displayed states in the interface control document. https://www.rfc-editor.org/info/rfc3428/ https://datatracker.ietf.org/doc/html/rfc5438 https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0 https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages 270 Translate success, failure, and delivery semantics Medium Unknown The gateway shall map user-blocked, app-uninstalled, policy-denied, and invalid-recipient failures to meaningful SIP/user responses. Clear failures allow users and operators to remediate interop issues rather than retry indefinitely. Uninstall/block the Teams bot for one user, remove a required permission for another, and send to an unmapped recipient. Attempt delivery from SIP. Gateway reports blocked/uninstalled as a permanent or policy failure; missing permission as administrative failure; unknown recipient as addressing failure. Tolerance: classification accuracy 100% across tested failure classes. Avoid exposing sensitive policy details to end users. https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0 https://datatracker.ietf.org/doc/html/rfc5438 280 Implement throttling, backpressure, and retry behavior High Unknown The gateway shall rate-limit its own calls, honor Teams Bot and Graph throttling responses, and retry transient failures using Retry-After or exponential backoff with jitter. Required to preserve interop under bursty chat loads without message loss or Teams-side 429 storms. Use a test stub or controlled load to trigger HTTP 429 from Graph or Bot Framework. Inspect retry timestamps and user delivery results. Gateway does not retry before Retry-After when provided; otherwise uses exponential backoff with jitter. Messages remain queued or fail explicitly after max retry policy. Tolerance: 0 early retries; 0 lost messages in durable-queue mode. Do not attempt to bypass service limits. https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/rate-limit https://learn.microsoft.com/en-us/graph/throttling 290 Implement throttling, backpressure, and retry behavior High Unknown The gateway shall expose backpressure to the SIP system when Teams-side queues exceed thresholds. Prevents unbounded queue growth and sets correct sender expectations during Teams-side impairment. Throttle the Teams side and send a burst of 1,000 SIP messages over 5 minutes. Observe queue depth, SIP responses, and eventual delivery/failure. Below threshold, messages are queued and delivered in order. Above threshold, gateway returns configured temporary failure/backoff. Tolerance: no process crash; queue-depth alarm within 60 s of threshold breach. Set thresholds based on operational CONOPS and storage limits. https://learn.microsoft.com/en-us/graph/throttling https://www.rfc-editor.org/info/rfc3428/ 300 Preserve ordering and suppress duplicates High Unknown The gateway shall maintain per-conversation ordering, idempotency keys, duplicate suppression, and replay protection using SIP message identifiers, CPIM headers where present, and Teams message IDs/correlation IDs. Ordering and duplicate control are essential for operational chat readability and reliable recovery after retries or reconnects. Send 100 numbered messages SIP-to-Teams and 100 Teams-to-SIP in one conversation without throttling. Receiving side displays all numbers in order after final delivery. Tolerance: 0 lost messages, 0 duplicates, 0 order inversions within each direction/conversation. Interleaving between opposite directions may be governed by arrival time and shall be documented. https://www.rfc-editor.org/info/rfc3428/ https://datatracker.ietf.org/doc/html/rfc3862 https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 https://learn.microsoft.com/en-us/graph/teams-changenotifications-chatmessage 310 Preserve ordering and suppress duplicates High Unknown The gateway shall not create duplicate user-visible messages of retries and recovery replays. Retries are unavoidable across Graph/Bot/SIP boundaries; duplicate suppression protects user trust. Force a network timeout after Teams accepts a message but before the gateway records success. Restart the gateway and replay the durable queue. Only one user-visible copy appears. Correlation log links the retry attempts to the same canonical message. Tolerance: 0 duplicates in 20 induced ambiguous-commit scenarios. Store remote IDs as soon as available. https://learn.microsoft.com/en-us/graph/throttling https://learn.microsoft.com/en-us/graph/teams-changenotifications-chatmessage https://datatracker.ietf.org/doc/html/rfc5438 320 Map presence states between SIP/SIMPLE and Teams Medium Unknown The gateway shall map Teams presence availability/activity to SIP presence notifications using PIDF, and shall map SIP presence to Teams-side presentation only where supported by Teams APIs and the chosen identity model. Presence differences directly affect user decisions to initiate chat; false availability creates failed communication attempts. Set a Teams user's status to Available, Busy, Do not disturb, Away, Be right back, and Offline. Subscribe from a SIP watcher and capture NOTIFY/PIDF. PIDF basic status and note/activity mapping match the approved state table. Tolerance: update visible to SIP watcher within <=5 minutes for normal cloud users; on-prem mailbox-associated presence may allow up to 60 minutes if applicable. Include mapping for PresenceUnknown/status unknown. https://www.rfc-editor.org/info/rfc3856/ https://www.rfc-editor.org/info/rfc3863/ https://learn.microsoft.com/en-us/graph/api/resources/presence?view=graph-rest-1.0 https://learn.microsoft.com/en-us/microsoftteams/presence-admins 330 Map presence states between SIP/SIMPLE and Teams Medium Unknown The gateway shall not falsely represented SIP-originated presence as native Teams user presence unless backed by a supported Teams identity and API path. Avoids showing SIP users as native Teams users when Teams cannot maintain their presence state. Publish SIP presence changes for a SIP-only user and for a mapped Entra-represented user, if such mapping is in scope. Observe Teams UI/bot card/status rendering. Supported mapped user: Teams-side presence/status representation updates according to API limits. SIP-only user: gateway provides a clearly labeled status in app/bot context or no presence, not a misleading native Teams presence. Tolerance: 0 false native-presence displays. Some programs may choose one-way Teams-to-SIP presence only. https://learn.microsoft.com/en-us/graph/api/resources/presence?view=graph-rest-1.0 https://www.rfc-editor.org/info/rfc3856/ https://www.rfc-editor.org/info/rfc3863/ 340 Maintain presence subscriptions and refresh behavior Medium Unknown The gateway shall support SIP SUBSCRIBE refresh/termination and Graph presence change-notification renewal or polling fallback according to API limits. Presence subscriptions expire; renewal failures create stale status and break interoperability expectations. Create SIP and Graph presence subscriptions, wait through at least two refresh cycles, then intentionally block renewal for one cycle. Successful cycles continue to emit correct NOTIFY/change events. Failed renewal marks presence stale or unknown within configured stale timer. Tolerance: stale timer <=2x subscription refresh interval unless API policy dictates longer. Do not continue showing stale Available indefinitely. https://www.rfc-editor.org/info/rfc3856/ https://learn.microsoft.com/en-us/graph/changenotifications-for-presence https://learn.microsoft.com/en-us/graph/api/presence-get?view=graph-rest-1.0 350 Handle typing, composing, read-receipt, and IMDN limitations Medium Unknown The gateway shall translate composing and disposition indications only where both sides support them and shall otherwise degrade predictably without creating chat-message noise. Typing/read-receipt feature asymmetry can confuse users if indications are silently fabricated or converted to normal messages. Send SIP isComposing active/idle events to a Teams 1:1 chat and to a Teams group chat with more than 20 members. Send Teams typing events if available through the selected API path. Where supported, the recipient sees a typing/composing indicator. Where unsupported, the event is dropped or logged as non-forwardable without creating a normal chat message. Tolerance: 0 visible text messages generated solely from typing events. Teams disables some features in private group chats over 20 participants; reflect that in expectations. https://datatracker.ietf.org/doc/rfc3994/ https://datatracker.ietf.org/doc/html/rfc5438 https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 360 Handle typing, composing, read-receipt, and IMDN limitations Medium Unknown Delivery/read receipts shall be mapped only to the level of evidence the gateway actually has. Prevents false read/display confirmations across platforms. Request IMDN delivery/display notifications from SIP. In Teams, test message accepted, recipient seen, and recipient not seen cases where the API exposes or does not expose read state. Gateway returns accepted/delivered/displayed only when evidence exists; otherwise returns unsupported or no display notification. Tolerance: 0 false displayed/read receipts. Read receipt availability may depend on chat size and policy. https://datatracker.ietf.org/doc/html/rfc5438 https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 370 Map 1:1, group chat, and channel topologies intentionally within the same information domain. High Unknown The gateway shall define how SIP 1:1, SIP multi-recipient/message list service, and SIP conference contexts map to Teams oneOnOne chats, group chats. Topology mismatch causes messages to reach the wrong audience or lose membership context. Create SIP 1:1, 3-party, and 25-party conversations and map them to Teams. Add and remove one participant where supported. 1:1 maps to Teams oneOnOne or both personal context as designed. Group maps to Teams group chat or channel according to policy. Roster changes propagate or are rejected explicitly. Tolerance: 0 unintended recipients; group chat roster <= Teams limits. Teams private chat supports up to 250 people; adding more than 200 at once is constrained. https://learn.microsoft.com/en-us/graph/api/resources/chat?view=graph-rest-1.0 https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams https://www.rfc-editor.org/rfc/rfc4575 380 Map 1:1, group chat, and channel topologies intentionally within the same information domain and other compatible limits. High Unknown The gateway shall reject topology conversions that would exceed Teams limits or SIP system limits. Prevents partial membership creation and message exposure to only a subset of intended recipients. Attempt to bridge a SIP conference or multi-recipient message with more than the configured Teams chat/channel membership limit. Gateway rejects before delivering content, or selects an approved alternate topology with explicit user notification. Tolerance: 0 partial audience delivery without warning. Program may select a lower operational maximum than Microsoft limits. https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams https://www.rfc-editor.org/rfc/rfc4575 400 Preserve or explicitly degrade threads, replies, mentions, and reactions Medium Unknown The gateway shall maintain a mapping for Teams channel root messages/replies, Teams mentions/reactions, and SIP/CPIM message threading or conference context. Unsupported constructs shall be downgraded visibly and safely. Preserves conversation context and avoids losing reply targets or actionable mentions across systems. Post a Teams channel root message and two replies, then respond from SIP to the second reply. Repeat with SIP-originated messages that carry a thread/correlation identifier. Teams replies remain under the intended root when supported. SIP users receive context such as quoted parent/correlation when native threading is unavailable. Tolerance: 0 replies attached to wrong Teams root in 20 test threads. Define canonical thread ID format. https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 https://datatracker.ietf.org/doc/html/rfc3862 https://datatracker.ietf.org/doc/html/rfc5438 410 Preserve or explicitly degrade threads, replies, mentions, and reactions Medium Unknown The gateway shall ensure that mentions and reactions shall not corrupt the underlying message text. Teams supports mentions and reactions that may not have SIP equivalents. Send Teams messages with @user, @team/channel/tag where permitted, emoji reactions, and importance flags. Send SIP messages containing literal @ text and emoji. Mentioned names render as readable text on SIP side with stable identifiers where configured. Reactions become optional notices or metadata, not altered message text. Tolerance: original message body has 0 semantic text loss. Notify users if a mention cannot alert a SIP recipient. https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 https://learn.microsoft.com/en-us/microsoftteams/limits-specifications-teams 440 Preserve timing, correlation, and diagnostic traceability High Unknown The gateway shall preserve original message time where available, record gateway accepted time, Teams/SIP accepted time, remote message IDs, and end-to-end correlation IDs in a searchable test log. Necessary to diagnose cross-protocol delays, duplicates, order inversions, and attribution disputes during interoperability testing. Send 20 messages in each direction while capturing SIP packets, Teams event payloads, gateway logs, and user-visible timestamps. Each message has one correlation ID linking SIP transaction, gateway queue record, Graph/Bot message/event ID, and final recipient. Gateway clock drift <=1 s from approved time source; displayed/metadata original time within <=5 s where both platforms expose it. Do not log classified/sensitive content unless the test environment is authorized. https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0 https://datatracker.ietf.org/doc/html/rfc3862 https://learn.microsoft.com/en-us/graph/teams-changenotifications-chatmessage 450 Recover from outages without losing or duplicating messages Medium Unknown The gateway shall use durable queues, subscription catch-up, idempotent replay, and health checks for SIP trunks, Teams Graph/Bot endpoints, and identity endpoints. Interop shall survive transient network/API failures without one-way loss or repeated messages. Start a bidirectional 50-message exchange, terminate the gateway process halfway, restart it, and continue traffic. Repeat while Teams-side Graph calls return transient 502/504. Durably accepted messages are delivered once after restart. New messages are accepted only when gateway health permits. Tolerance: 0 lost durable messages, 0 duplicates, recovery to steady state <=5 minutes after dependencies are available. Messages not durably accepted before crash may be legitimately retried by the sender. https://learn.microsoft.com/en-us/graph/teams-changenotifications-chatmessage https://learn.microsoft.com/en-us/graph/throttling https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/rate-limit https://www.rfc-editor.org/info/rfc3428/ 460 Recover from outages without losing or duplicating messages Medium Unknown The gateway shall ensure that health checks shall detect loss of SIP peer connectivity and Teams-side API reachability and expose route status to both operations and, where appropriate, users. Prevents users from believing the other system is reachable when the bridge is down. Block SIP peer TCP/TLS and then block DoW Graph/Bot endpoint access. Observe gateway health, SIP responses, and Teams-side user notification behavior. Gateway marks the affected route degraded/unavailable within 60 s, stops promising delivery, and recovers automatically when connectivity returns. Tolerance: 0 messages accepted as delivered while route is known unavailable. User-facing notices shall be rate-limited to avoid notification storms. https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-u-s-government-DoW-endpoints?view=o365-worldwide https://learn.microsoft.com/en-us/microsoft-365/enterprise/microsoft-365-ip-web-service?view=o365-worldwide https://www.rfc-editor.org/info/rfc3428/

&"-,Bold"&24DRAFT&"-,Regular"&11 &"-,Bold"&16DISA INTEROPERABILITY REQUIREMENTS TEMPLATE FOR CHAT

&"-,Bold"&24DRAFT &P OF &N

STIG CANDIDATES

https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/conversations/send-proactive-messages https://datatracker.ietf.org/doc/html/rfc3862 430 Preserve source attribution and avoid spoofing High Unknown The gateway shall ensure that SIP messages generated from Teams shall include sender and context in CPIM/SIP headers or gateway metadata. Enables the SIP side to render the true Teams author and route replies correctly. Send Teams messages from two users in the same group/channel, then capture SIP messages. SIP recipient sees the actual Teams sender display name and stable mapped address, plus conversation context. Tolerance: 0 messages attributed to the gateway itself unless clearly labeled as a bridge notice. Display name alone is insufficient for routing; include stable mapped identity internally. https://datatracker.ietf.org/doc/html/rfc3862 https://learn.microsoft.com/en-us/graph/api/resources/chatmessage?view=graph-rest-1.0