An offer proposes; an answer selects
SDP describes a session but does not transport its media. In the offer/answer model, one side proposes media streams and the other answers them. Start by identifying that pair of messages. An INVITE can carry the offer, but delayed offers and reliable provisional responses allow other placements. The answer must correspond to the offered media sections in order. A rejected stream uses a zero port rather than disappearing from the answer. Media-level attributes can override session-level defaults, so reading only the first connection address is insufficient.
Read one audio section completely
- Find the connection address and media port, considering ICE when present.
- Compare transport profile and compatible codecs, including clock rate and format parameters.
- Map dynamic payload types through rtpmap instead of guessing from the number.
- Compare sendrecv, sendonly, recvonly or inactive direction.
- Identify security and RTCP attributes relevant to the negotiated transport.
- A shared codec name is not always enough: parameters and the actual media profile must also be compatible. An accepted audio stream still needs a working network path.
Follow later changes
For a hold or transfer problem, keep the initial accepted description and each later offer/answer pair. Do not overwrite your notes with the newest SDP until the exchange succeeds. A failed renegotiation is not evidence that the rejected parameters became active. In a PBX, the two call legs negotiate independently. The PBX may relay, mix or transcode media, so one leg's codec and address need not match the other. Draw those two negotiated relationships before changing codec lists globally.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.