SDP offer/answer examples for https://srvscripts.com/tools/sdp-offer-answer-comparator/

Each case is a pair of files: NN-name.offer.sdp and NN-name.answer.sdp. Paste the offer into the first box of the
comparator and the answer into the second. expected-results.txt shows what the comparator reports for each pair, and
expected-results.csv lists the expected result in one line per case.

  01-lab-pcmu-pcma          real capture from our FreePBX 17 lab, with the RTP of the same call (see below)
  02-hold-dtmf-missing      answer puts the call on hold (sendonly) and drops telephone-event
  03-no-common-codec        G.729 only against PCMU only: 488 or no audio
  04-srtp-vs-rtp            SRTP (SDES) offer answered with plain RTP
  05-rejected-video         video refused with port 0, audio accepted (valid)
  06-dtmf-payload-renumbered telephone-event 101 in the offer, 96 in the answer
  07-webrtc-dtls-ice        Opus over DTLS-SRTP with ICE and rtcp-mux, nothing wrong
  08-broken-port            port 99999: broken SDP, reported as an error instead of compared

Cases 02 to 08 are synthetic: documentation addresses (203.0.113.10, 198.51.100.20), invented keys, fingerprints and
ICE passwords. How each expectation was checked: we wrote the expected result for every case from the RFC rules first,
then ran the comparator (version of 18 October 2026) and confirmed that its findings contain each expected line and none
of the excluded ones. The same pairs run as automated tests on every change to the tool.

Accepted codecs are not the codec on the wire
  The SDP answer lists the codecs both sides accept. RFC 3264 says the first one SHOULD be used, and either side may
  switch to another accepted codec at any time. Case 01 shows it: the answer put PCMU first, yet every RTP packet in
  both directions carried PCMA (payload type 8). See 01-lab-pcmu-pcma.rtp-observed.txt and the capture
  01-lab-pcmu-pcma.rtp.pcap (RTP only; the SIP messages, which include digest authentication, were removed).

  To see the codec actually sent on your own call:
    tcpdump -i any -n -w call.pcap udp            # during the call, on the PBX or a SPAN port
    tshark -r call.pcap -d udp.port==RTP_PORT,rtp -Y rtp -T fields -e ip.src -e ip.dst -e rtp.p_type | sort | uniq -c
      (RTP_PORT is a port from an m= line; payload type 0 = PCMU, 8 = PCMA, 9 = G.722, 18 = G.729; 96-127 are
       dynamic and mean what the a=rtpmap lines say)
    asterisk -rx "core show channel CHANNEL"      # ReadFormat / WriteFormat while the call is up
  Encrypted media (SRTP) still shows the payload type in the clear RTP header.

Licence: these example files may be copied and reused freely. Checked on 18 October 2026.