RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model

Publisher

IETF / RFC Editor

URL

https://www.rfc-editor.org/rfc/rfc6337.html

Published

2011-08-01

Updated

unknown

Accessed

2026-09-24

HTTP status

200

License

IETF Trust legal provisions; RFC text may be reproduced with attribution; short excerpts and locators only

Source notes citing this source

• RFC 6337 recommends that a UAS send an SDP answer reliably, if possible, before it starts sending early media. in context
• RFC 6337 says that once a UAS has sent the answer in a reliable provisional response it should not include SDP in later responses to the INVITE, and a UAC should be ready to receive and ignore such SDP from non-conforming peers. in context
• RFC 6337 says a UAC receiving SDP in an unreliable provisional response should act as if it received the answer, but must not send a new offer until it receives the same SDP in a reliable non-failure response. in context
• RFC 6337 treats SDP in an unreliable provisional response before any reliable response as a preview of the answer; the actual answer is the first SDP in a reliable non-failure response. in context
• RFC 6337's general principle is that a UA's offer states what it and its user want to do at that time regardless of what the other party indicated previously. in context
• RFC 6337 says a UA may initiate hold by offering inactive instead of sendonly if it does not intend to transmit any media while on hold. in context
• RFC 6337 notes that the sendonly hold model assumes the holding UA will play music on hold and that this is not always the case. in context
• RFC 6337 says a UA already placed on hold with inactive that then wants to initiate its own hold also using inactive need not send a new offer. in context
• RFC 6337 says that when both sides are on hold each side must clear its own hold state and the first UA to come off hold sends an offer with sendrecv. in context
• RFC 6337 on SIP usage of the offer/answer model is an Informational RFC published August 2011. in context
• RFC 6337 says an answer to an offer with c=IN IP4 0.0.0.0 must still choose its direction attribute from the direction attribute of the offered stream. in context
• RFC 6337 describes hold as an offer with a=sendonly on each held stream answered with a=recvonly, or alternatively an offer with a=inactive when the holder will send no media. in context
• A UA that receives an INVITE (including a re-INVITE) carrying an unacceptable offer should respond 488, preferably with a Warning header field giving the reason. in context
• An offer that arrives in a response (for example in a 2xx to a delayed-offer INVITE) cannot be rejected with 488; the UA should answer it and then start a new offer/answer exchange to fix parameters, or terminate the session. in context
• RFC 6337 cautions that if media is already flowing using a re-INVITE's new offer, the UA should send a 2xx instead of 488 and then correct parameters with UPDATE or terminate. in context
• RFC 6337, which gives the 488 guidance for rejecting offers, is an Informational RFC rather than a standards-track specification. in context
• A UA that receives an UPDATE carrying an offer it cannot accept should respond 488, preferably with a Warning header field giving the reason. in context

Cite this source record

APA

WarmTransfer. (2011, August 1). RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model. WarmTransfer. https://warmtransfer.net/knowledge/sources/rfc-6337-offer-answer-usage

BibTeX

@misc{warmtransfer-rfc-6337-offer-answer-usage,
  title  = {RFC 6337: Session Initiation Protocol (SIP) Usage of the Offer/Answer Model},
  author = {{WarmTransfer}},
  year   = {2011},
  url    = {https://warmtransfer.net/knowledge/sources/rfc-6337-offer-answer-usage},
  note   = {IETF / RFC Editor, accessed 2026-09-24}
}