Camera Sharing & Partner Integration Guide

Technical Architecture

Proven Architecture Patterns

Experience with thousands of partner integrations has demonstrated that complete isolation between camera infrastructure and partner access provides the only sustainable long-term architecture. This approach balances security requirements with operational flexibility.

Traditional (Problematic) Approach:
Cameras ──RTSP──> Partner Systems ──> Their Users
         ↑
         └── Direct access = Security nightmare

WINK Media Router Approach:
Cameras ──RTSP──> WINK Router ──HLS/RTSP/SRT──> Partner Endpoint ──> Their Users
         ↑            ↑                              ↑
         Safe     Control Point                   Isolated
         Internal    Monitoring                    No camera access
                     Rate limits
                     Auth checks
                     Usage logs
            

Protocol Selection Guide

October 2024 perspective: After twelve years of production deployments, here's what actually works:

HLS + OTP: The Workhorse (70% of Partners)

• Latency: 3-5 seconds (and that's fine for most use cases)
• Why it wins: Works everywhere, CDN-friendly, easy revocation
• Real example: Local news ingesting 200 traffic cameras for web display
• Don't use for: PTZ control, emergency response requiring real-time

RTSP + IP Whitelist: The Integration Standard (25% of Partners)

• Latency: 200-500ms
• Why it works: Every VMS speaks RTSP, reliable for fixed locations
• Real example: County EOC integrating city cameras into Genetec
• Don't use for: Mobile users, frequently changing IPs

SRT + Pre-shared Key: The Professional Choice (4% of Partners)

• Latency: 500ms-1s with excellent reliability
• Why it's rare but valuable: Broadcast quality, handles packet loss
• Real example: TV station broadcast truck for live shots
• Don't use for: Simple web viewing (overkill)

WebRTC: The Unicorn (1% of Partners)

• Latency: 200-500ms
• Why it's rare: Complex setup, STUN/TURN requirements
• Real example: Interactive PTZ control portal
• Don't use unless: You absolutely need bi-directional communication

Codec Configuration and Transcoding

Let's be crystal clear about our codec policy as of October 2024:

Video Codec: H.264 Baseline Profile
Resolution: Source (no upscaling, downscaling on request)
Bitrate: Adaptive 400kbps - 4Mbps
Framerate: Source (typically 10-30fps)
GOP Size: 2 seconds (60 frames @ 30fps)
Audio: AAC 64kbps mono (if present)
Container: Depends on protocol (TS for HLS, RTP for RTSP)
                

Want something different? Here's the process:

1. Technical Justification Required
   • "We want H.265" is not sufficient
   • "We need H.265 because we have limited bandwidth and 4K cameras" is better
   • Include bandwidth calculations and device compatibility analysis
2. Upstream Approval Mandatory
   • Camera owner must approve in writing
   • We don't make unilateral transcoding decisions
   • Some agencies have policies against certain codecs
3. Testing Period
   • 2-week trial with monitoring
   • Performance metrics collected
   • Rollback if issues detected

Monitoring and Abuse Detection

Our heuristic monitoring system (refined continuously since 2021) watches for these patterns:

# Suspicious Patterns That Trigger Alerts

1. Credential Sharing Indicators:
   - Same token used from >3 distinct IPs within 1 hour
   - Geographic impossibility (NYC and LA within minutes)
   - User-agent changes mid-session

2. Bandwidth Abuse:
   - Sustained usage >80% of limit for >1 hour
   - Spike to >200% of normal without prior notice
   - Downloading rather than streaming (rapid segment requests)

3. Unauthorized Redistribution:
   - Multiple identical streams from same source
   - Reverse proxy signatures in requests
   - CDN headers in requests (CloudFlare, Akamai, etc.)

4. System Abuse:
   - >10 auth failures per minute
   - Connection rate >20/minute sustained
   - Attempting to access non-authorized cameras

Automated Responses:
Level 1 (Warning): Email to technical contact
Level 2 (Throttle): Bandwidth reduced to 50%
Level 3 (Suspend): Access blocked, manual review required
Level 4 (Terminate): Partnership ended, legal notified
            

Security Implementation

Defense in Depth: How We Protect Your Cameras

Security isn't a feature , it's the foundation. Here's our multi-layer approach as implemented in WINK Media Router 2.x:

Layer 1: Network Isolation

Camera Network (Private) | WINK Media Router | Partner Network (DMZ) | Internet
    10.0.0.0/8          |   Proxy/Firewall   |    172.16.0.0/12     | Public IPs
    No routes out       |   State inspection |    Limited routes    | Full exposure
                        |   Rate limiting    |
            

Layer 2: Authentication

// Token Generation (Server Side)
function generateOTP($partnerId, $cameraList, $duration = 10) {
    $token = [
        'pid' => $partnerId,
        'cams' => $cameraList,
        'exp' => time() + ($duration * 60),
        'ip' => $_SERVER['REMOTE_ADDR'],
        'sig' => null
    ];
    
    // Sign token to prevent tampering
    $token['sig'] = hash_hmac('sha256', json_encode($token), SECRET_KEY);
    
    // Store in Redis for quick validation
    Redis::setex("otp:{$token}", $duration * 60, json_encode($token));
    
    return base64_encode(json_encode($token));
}

// Token Validation (Every Request)
function validateOTP($token) {
    // Check Redis first (fast path)
    if (!Redis::exists("otp:{$token}")) {
        logSecurityEvent('Invalid token attempt', $token);
        return false;
    }
    
    $data = json_decode(base64_decode($token), true);
    
    // Verify signature
    $sig = hash_hmac('sha256', json_encode(array_diff_key($data, ['sig' => 1])), SECRET_KEY);
    if ($sig !== $data['sig']) {
        logSecurityEvent('Tampered token detected', $token);
        return false;
    }
    
    // Check expiration
    if ($data['exp'] < time()) {
        Redis::del("otp:{$token}");
        return false;
    }
    
    return $data;
}
                

Layer 3: Rate Limiting and DDoS Protection

The Media Router implements sophisticated rate limiting to prevent abuse while allowing legitimate usage:

Rate Limiting Configuration:

Authentication Endpoints:
- 1 request per second baseline
- Burst allowance: 5 requests
- Exceeded: HTTP 429 response

Stream Endpoints:
- 100 requests per second for segments
- 25 concurrent connections per IP
- Burst handling for player buffering

Protection Mechanisms:
- Connection rate limiting (prevents scanning)
- Geographic anomaly detection
- Bandwidth quota enforcement
- Automatic temporary blocking for violations
            

Layer 4: Audit Logging

Every access is logged with:

• Timestamp (millisecond precision)
• Partner ID and token used
• Source IP and user agent
• Camera accessed
• Bandwidth consumed
• Session duration
• Any security events (auth failures, limit exceeded)

JWT vs OTP: When to Use Each

October 2024 guidance based on twelve years of production use:

Troubleshooting

The Top 10 Support Tickets (and How to Avoid Them)

1. "The stream won't play"

Checklist:
□ Is your IP whitelisted? curl -I https://router.agency.gov/health
□ Is your token valid? Check expiration time
□ Is the camera actually online? We don't control upstream
□ Are you using the right protocol? HLS needs .m3u8, not .rtsp
□ Console errors? CORS issues mean you need proper headers
            

2. "Why is there a 5-second delay?"

Answer: You're using HLS. HLS segments are typically 2 seconds each, and players buffer 2-3 segments. This is normal. If you need lower latency, use RTSP or SRT. For a comprehensive analysis of protocol characteristics and latency trade-offs, refer to our Protocol Comparison for Long-Distance Streaming guide.

3. "The stream keeps disconnecting"

Common causes:
1. Token expired (check timestamp)
2. Hitting rate limits (check your usage)
3. Network issues (run traceroute)
4. Player timeout (increase buffer size)
5. We're enforcing limits (check your email)
            

4. "Can you increase our bandwidth limit?"

Answer: Yes, but first show us your usage patterns. If you're constantly at 80%+, you probably need your own WINK Media Router license.

5. "Our IP address changed"

Answer: This is why we recommend OTP. If you're updating IPs more than monthly, switch to OTP.

6. "Can we get all cameras?"

Answer: No. You get access to specific cameras based on your agreement. Request additions through proper channels.

7. "The quality is poor"

Quality is determined by:
1. Source camera (we don't upscale)
2. Bandwidth allocation (more bandwidth = higher quality)
3. Network conditions (packet loss degrades quality)
4. Player settings (check if player is requesting lower quality)
            

8. "Can you remove the watermark?"

Answer: There is no watermark from WINK Media Router. If you see one, it's from the source camera or your player.

9. "Integration works locally but not in production"

Usually means:
- Production firewall blocking ports
- Production proxy interfering (see CloudFlare warnings)
- Different network path with more restrictions
- SSL certificate issues (check cert chain)
            

10. "Stream works for 10 minutes then stops"

Answer: Your OTP token expired. Tokens default to 10 minutes unless explicitly set longer. Implement token refresh in your application or request longer duration tokens if appropriate for your use case.

When to Contact Support vs When to Check Your Setup