Case 01: what the SDP says compared with what the RTP carried (real lab call, 18 Oct 2026, 07:06 UTC)

Lab: FreePBX 17.0.33.2, Asterisk 22.11.0 (Debian 12). Caller: a SIPp test phone registered as extension 1002, calling
the echo test (*43). Both ends run on the same server, so all addresses are 127.0.0.1.

SDP
  Offer (INVITE from the phone):   m=audio 26000 RTP/AVP 0 8    -> PCMU first, then PCMA
  Answer (200 OK from Asterisk):   m=audio 14202 RTP/AVP 0 8    -> PCMU first, PCMA also accepted
  Comparator: "first common codec in the answer: PCMU/8000 (payload type 0); also accepted: PCMA/8000"

What the phone sent
  The test phone was told to send PCMA only (payload type 8), which RFC 3264 allows because both sides accepted PCMA.

RTP captured on the same call (tcpdump on the loopback interface; SIP removed from the published capture)
  tshark -r 01-lab-pcmu-pcma.rtp.pcap -d udp.port==26000,rtp -Y rtp -T fields -e ip.src -e udp.srcport -e udp.dstport -e rtp.p_type | sort | uniq -c
      600 127.0.0.1  26000  14202  8     phone -> Asterisk, payload type 8 (PCMA), 0.00 s to 11.98 s
      549 127.0.0.1  14202  26000  8     Asterisk -> phone, payload type 8 (PCMA), 1.01 s to 11.97 s
  No packet with payload type 0 (PCMU) in either direction.

Asterisk during the call
  asterisk -rx "core show channel PJSIP/1002-0000022a"
      NativeFormats: (alaw)
        WriteFormat: alaw
         ReadFormat: alaw
            Formats: (ulaw|alaw)     <- what was negotiated
  (core show channels concise lists the channel name.)

Conclusion
  The answer's first codec was PCMU, but the call ran on PCMA in both directions. The SDP shows which codecs each side
  accepts; only the RTP (payload type in the packets) or the channel's read/write format shows what is actually sent.
  This is one call on one lab server, not a survey of phones: other devices may follow the answer's order strictly.