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

Publisher

IETF / RFC Editor

URL

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

Published

2011-08-01

Updated

unknown

Accessed

2026-09-30

HTTP status

200

License

IETF Trust Legal Provisions; no-redistribution; short excerpts and locators only

Source notes citing this source

• The conventional acknowledgement of a hold offer carrying a=sendonly is an answer carrying a=recvonly; RFC 6337 notes RFC 3264 describes this in non-normative language. in context
• An offer sent in response to an offerless re-INVITE should include all codecs the UA is currently willing and able to use, not only those negotiated in earlier offer/answer exchanges. in context
• RFC 6337 warns that unless a UA offers a=sendrecv when it has no hold of its own to maintain, calls can become stuck on hold, especially when a third-party call controller is involved. in context
• An agent is still required to be able to receive SDP with a connection address of 0.0.0.0, which means neither RTP nor RTCP should be sent to the peer. 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-b

BibTeX

@misc{warmtransfer-rfc-6337-offer-answer-usage-b,
  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-b},
  note   = {IETF / RFC Editor, accessed 2026-09-30}
}