Paul already answered your question, but as a side note - I strongly encourage you to NEVER put a 100rel in a Require header. What you're basically saying by doing that is: "this call CANNOT and MUST NOT succeed if the far-end UAS it reaches doesn't support reliable provisional responses". Very few people actually mean that, because very few of their customers/users actually want calls to fail. (and trust me, calls will fail because 100rel is not ubiquitous)
Some developers put it in Require because they think their products will be deployed only with their own gear and thus the INVITE will always go to something that supports 100rel - but even in that case you don't need to put it in Require, since putting it in Supported is sufficient. -hadriel > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Michael > Hirschbichler > Sent: Thursday, May 06, 2010 8:58 AM > To: SIPImplementors > Subject: [Sip-implementors] "require" and "supported"-Header regarding > reliable Responses > > Hi all, > > we are currently discussing if it is possible (and - esp. - allowed) to > set both, a "Require:"- and a "Supported:"-Header with the > "100rel"-option in the same INVITE-Request. In my opinion, if 100rel is > set in the "Require:"-header, it is implicitely also supported and > should not explicitely set in the "Supported:"-header. > Is this assumption correct? How should a UAS react, if this option is > set twice (*Supported:* and *Required*)? > > Thx in advance and BR > Michael > > > RFC3262, 8.1: 100rel > Description: This option tag is for reliability of provisional > responses. When present in a *Supported* header, it indicates > that the UA can *send* *or* *receive* reliable provisional > responses. > When present in a *Require* header in a request, it indicates > that the *UAS* *MUST* *send* all provisional responses > reliably. > When present in a Require header in a reliable provisional > response, it indicates that the response is to be sent > reliably. > > > Read more: http://www.faqs.org/rfcs/rfc3262.html#ixzz0n9ZAm3Xu > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
