{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/test-rtsp-session-survival-across-firewalls-and-idle-periods/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/",
        "slug": "test-rtsp-session-survival-across-firewalls-and-idle-periods",
        "url": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/test-rtsp-session-survival-across-firewalls-and-idle-periods/"
        },
        "title": "Test RTSP session survival across firewalls and idle periods",
        "summary": "RTSP is stateful and includes session timeout behavior. Verify keepalives, transport choices, recovery, and version support through the exact production path.",
        "format": {
            "slug": "checklist",
            "name": "Checklist"
        },
        "priority": {
            "slug": "advisory",
            "name": "Advisory"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            },
            {
                "slug": "video-surveillance",
                "name": "Video Surveillance",
                "url": "https://update.dsesecurity.com/topic/video-surveillance/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-08-25T21:36:03+00:00",
        "modified_at": "2026-08-25T21:36:17+00:00",
        "reviewed_on": "2026-08-25",
        "reading_minutes": 2,
        "word_count": 411,
        "potentially_affected": "Systems carrying RTSP-controlled video through firewalls, NAT, WAN links, proxies, media gateways, or intermittently used viewing paths.",
        "dse_recommendation": "Document the negotiated RTSP version, media transport, session timeout, keepalive method, and reconnect behavior, then test them beyond the longest expected idle period.",
        "primary_source": {
            "name": "RFC 7826 - Real-Time Streaming Protocol Version 2.0",
            "url": "https://www.rfc-editor.org/info/rfc7826/",
            "published_on": null,
            "authority": "www.rfc-editor.org"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p><strong>Bottom line:</strong> an RTSP stream that starts successfully may still fail after an idle interval, firewall-state change, endpoint restart, or transport fallback. Commission session survival and recovery, not just the first PLAY request.</p>\n<h2>Source fact: RTSP controls stateful media sessions</h2>\n<p><a href=\"https://www.rfc-editor.org/info/rfc7826/\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 7826</a> specifies RTSP 2.0 for setting up and controlling real-time media delivery. It describes transport choices that can include UDP, multicast, and TCP, and it defines stateful sessions with timeout behavior. The specification describes a normal session timeout of 60 seconds unless a server indicates another value and recommends SET_PARAMETER as a keepalive method. It also states that RTSP 2.0 is not wire compatible with RTSP 1.0.</p>\n<p>These are protocol facts, not a claim that any camera uses RTSP 2.0. Many surveillance devices implement a documented subset or a different version, so observed and vendor-documented behavior governs the deployment.</p>\n<h2>Source boundary and applicability</h2>\n<p>The RFC does not certify camera/VMS interoperability, dictate firewall timers, or guarantee recovery from network loss. Products may use RTSP 1.0, vendor extensions, HTTP tunneling, or another media workflow. Consult the exact vendor documentation and applicable RFC version before forming a test expectation.</p>\n<h2>Applicability questions</h2>\n<ul>\n<li>Which RTSP version and methods do both endpoints document and negotiate?</li>\n<li>Is RTP delivered over UDP, multicast, interleaved TCP, or another supported path?</li>\n<li>What timeout does the server advertise, and what keepalive does the client send?</li>\n<li>Which firewall, proxy, NAT, or load balancer has a shorter state timer?</li>\n<li>Does recovery preserve timestamps, credentials, stream profile, and recording continuity?</li>\n</ul>\n<h2>DSE recommendation: test start, idle, interruption, and recovery</h2>\n<p><em>The following steps are DSE recommendations based on the cited source.</em></p>\n<p>Record a sanitized session trace or product log showing the actual version, Session header, timeout, transport, ports, and keepalive method. Allow the connection to remain in each production idle state beyond the shortest configured timer. Then test a dropped media path, dropped control path, firewall-state expiration, camera restart, and client restart in an approved environment.</p>\n<p>Measure detection and reconnection time and inspect the recorder timeline around every event. Align firewall policy with the supported transport and least access necessary; do not broadly expose RTSP or weaken controls merely to mask an ununderstood timeout.</p>\n<h2>Verification and evidence</h2>\n<p>Retain the endpoint/version inventory, vendor support references, sanitized negotiation trace, firewall rule and timer record, test timestamps, native clips, reconnect logs, alert evidence, and approved exception for any unresolved gap. Protect traces because URLs or headers can contain credentials or sensitive addresses.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/info/rfc7826/\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 7826 &#8211; Real-Time Streaming Protocol Version 2.0</a> &#8211; RFC Editor</li>\n</ul>",
        "content_text": "Bottom line: an RTSP stream that starts successfully may still fail after an idle interval, firewall-state change, endpoint restart, or transport fallback. Commission session survival and recovery, not just the first PLAY request.\nSource fact: RTSP controls stateful media sessions\nRFC 7826 specifies RTSP 2.0 for setting up and controlling real-time media delivery. It describes transport choices that can include UDP, multicast, and TCP, and it defines stateful sessions with timeout behavior. The specification describes a normal session timeout of 60 seconds unless a server indicates another value and recommends SET_PARAMETER as a keepalive method. It also states that RTSP 2.0 is not wire compatible with RTSP 1.0.\nThese are protocol facts, not a claim that any camera uses RTSP 2.0. Many surveillance devices implement a documented subset or a different version, so observed and vendor-documented behavior governs the deployment.\nSource boundary and applicability\nThe RFC does not certify camera/VMS interoperability, dictate firewall timers, or guarantee recovery from network loss. Products may use RTSP 1.0, vendor extensions, HTTP tunneling, or another media workflow. Consult the exact vendor documentation and applicable RFC version before forming a test expectation.\nApplicability questions\n\nWhich RTSP version and methods do both endpoints document and negotiate?\nIs RTP delivered over UDP, multicast, interleaved TCP, or another supported path?\nWhat timeout does the server advertise, and what keepalive does the client send?\nWhich firewall, proxy, NAT, or load balancer has a shorter state timer?\nDoes recovery preserve timestamps, credentials, stream profile, and recording continuity?\n\nDSE recommendation: test start, idle, interruption, and recovery\nThe following steps are DSE recommendations based on the cited source.\nRecord a sanitized session trace or product log showing the actual version, Session header, timeout, transport, ports, and keepalive method. Allow the connection to remain in each production idle state beyond the shortest configured timer. Then test a dropped media path, dropped control path, firewall-state expiration, camera restart, and client restart in an approved environment.\nMeasure detection and reconnection time and inspect the recorder timeline around every event. Align firewall policy with the supported transport and least access necessary; do not broadly expose RTSP or weaken controls merely to mask an ununderstood timeout.\nVerification and evidence\nRetain the endpoint/version inventory, vendor support references, sanitized negotiation trace, firewall rule and timer record, test timestamps, native clips, reconnect logs, alert evidence, and approved exception for any unresolved gap. Protect traces because URLs or headers can contain credentials or sensitive addresses.\nOfficial references\n\nRFC 7826 – Real-Time Streaming Protocol Version 2.0 – RFC Editor",
        "content_markdown": "Bottom line: an RTSP stream that starts successfully may still fail after an idle interval, firewall-state change, endpoint restart, or transport fallback. Commission session survival and recovery, not just the first PLAY request.\n\n## Source fact: RTSP controls stateful media sessions\n\n[RFC 7826](https://www.rfc-editor.org/info/rfc7826/) specifies RTSP 2.0 for setting up and controlling real-time media delivery. It describes transport choices that can include UDP, multicast, and TCP, and it defines stateful sessions with timeout behavior. The specification describes a normal session timeout of 60 seconds unless a server indicates another value and recommends SET_PARAMETER as a keepalive method. It also states that RTSP 2.0 is not wire compatible with RTSP 1.0.\n\nThese are protocol facts, not a claim that any camera uses RTSP 2.0. Many surveillance devices implement a documented subset or a different version, so observed and vendor-documented behavior governs the deployment.\n\n## Source boundary and applicability\n\nThe RFC does not certify camera/VMS interoperability, dictate firewall timers, or guarantee recovery from network loss. Products may use RTSP 1.0, vendor extensions, HTTP tunneling, or another media workflow. Consult the exact vendor documentation and applicable RFC version before forming a test expectation.\n\n## Applicability questions\n\n- Which RTSP version and methods do both endpoints document and negotiate?\n\n- Is RTP delivered over UDP, multicast, interleaved TCP, or another supported path?\n\n- What timeout does the server advertise, and what keepalive does the client send?\n\n- Which firewall, proxy, NAT, or load balancer has a shorter state timer?\n\n- Does recovery preserve timestamps, credentials, stream profile, and recording continuity?\n\n## DSE recommendation: test start, idle, interruption, and recovery\n\nThe following steps are DSE recommendations based on the cited source.\n\nRecord a sanitized session trace or product log showing the actual version, Session header, timeout, transport, ports, and keepalive method. Allow the connection to remain in each production idle state beyond the shortest configured timer. Then test a dropped media path, dropped control path, firewall-state expiration, camera restart, and client restart in an approved environment.\n\nMeasure detection and reconnection time and inspect the recorder timeline around every event. Align firewall policy with the supported transport and least access necessary; do not broadly expose RTSP or weaken controls merely to mask an ununderstood timeout.\n\n## Verification and evidence\n\nRetain the endpoint/version inventory, vendor support references, sanitized negotiation trace, firewall rule and timer record, test timestamps, native clips, reconnect logs, alert evidence, and approved exception for any unresolved gap. Protect traces because URLs or headers can contain credentials or sensitive addresses.\n\n## Official references\n\n- [RFC 7826 – Real-Time Streaming Protocol Version 2.0](https://www.rfc-editor.org/info/rfc7826/) – RFC Editor"
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/",
                "url": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-25"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Test RTSP session survival across firewalls and idle periods",
                        "item": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/#article",
                "identifier": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/",
                "url": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/",
                "headline": "Test RTSP session survival across firewalls and idle periods",
                "description": "RTSP is stateful and includes session timeout behavior. Verify keepalives, transport choices, recovery, and version support through the exact…",
                "abstract": "RTSP is stateful and includes session timeout behavior. Verify keepalives, transport choices, recovery, and version support through the exact production path.",
                "articleBody": "Bottom line: an RTSP stream that starts successfully may still fail after an idle interval, firewall-state change, endpoint restart, or transport fallback. Commission session survival and recovery, not just the first PLAY request.\nSource fact: RTSP controls stateful media sessions\nRFC 7826 specifies RTSP 2.0 for setting up and controlling real-time media delivery. It describes transport choices that can include UDP, multicast, and TCP, and it defines stateful sessions with timeout behavior. The specification describes a normal session timeout of 60 seconds unless a server indicates another value and recommends SET_PARAMETER as a keepalive method. It also states that RTSP 2.0 is not wire compatible with RTSP 1.0.\nThese are protocol facts, not a claim that any camera uses RTSP 2.0. Many surveillance devices implement a documented subset or a different version, so observed and vendor-documented behavior governs the deployment.\nSource boundary and applicability\nThe RFC does not certify camera/VMS interoperability, dictate firewall timers, or guarantee recovery from network loss. Products may use RTSP 1.0, vendor extensions, HTTP tunneling, or another media workflow. Consult the exact vendor documentation and applicable RFC version before forming a test expectation.\nApplicability questions\n\nWhich RTSP version and methods do both endpoints document and negotiate?\nIs RTP delivered over UDP, multicast, interleaved TCP, or another supported path?\nWhat timeout does the server advertise, and what keepalive does the client send?\nWhich firewall, proxy, NAT, or load balancer has a shorter state timer?\nDoes recovery preserve timestamps, credentials, stream profile, and recording continuity?\n\nDSE recommendation: test start, idle, interruption, and recovery\nThe following steps are DSE recommendations based on the cited source.\nRecord a sanitized session trace or product log showing the actual version, Session header, timeout, transport, ports, and keepalive method. Allow the connection to remain in each production idle state beyond the shortest configured timer. Then test a dropped media path, dropped control path, firewall-state expiration, camera restart, and client restart in an approved environment.\nMeasure detection and reconnection time and inspect the recorder timeline around every event. Align firewall policy with the supported transport and least access necessary; do not broadly expose RTSP or weaken controls merely to mask an ununderstood timeout.\nVerification and evidence\nRetain the endpoint/version inventory, vendor support references, sanitized negotiation trace, firewall rule and timer record, test timestamps, native clips, reconnect logs, alert evidence, and approved exception for any unresolved gap. Protect traces because URLs or headers can contain credentials or sensitive addresses.\nOfficial references\n\nRFC 7826 – Real-Time Streaming Protocol Version 2.0 – RFC Editor",
                "datePublished": "2026-08-25T21:36:03+00:00",
                "dateModified": "2026-08-25T21:36:17+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/test-rtsp-session-survival-across-firewalls-and-idle-periods/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Test RTSP session survival across firewalls and idle periods"
                },
                "articleSection": [
                    "Networks & Infrastructure",
                    "Video Surveillance"
                ],
                "keywords": [
                    "Networks & Infrastructure",
                    "Video Surveillance",
                    "Checklist",
                    "Advisory priority"
                ],
                "genre": "Checklist",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Video Surveillance",
                        "url": "https://update.dsesecurity.com/topic/video-surveillance/"
                    }
                ],
                "wordCount": 411,
                "timeRequired": "PT2M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "RFC 7826 - Real-Time Streaming Protocol Version 2.0",
                    "url": "https://www.rfc-editor.org/info/rfc7826/"
                }
            }
        ]
    }
}