Hello, Iñaki Baz Castillo wrote: > El Miércoles, 1 de Octubre de 2008, Dmitry Akindinov escribió: >> Hello, >> >> I have a question on rfc 3262. The document lists the Contact header as >> optional in 18x provisional responses that require reliable handling >> (Require: 100rel). > > Have you ever seen a 1XX requiring PRACK with no Contact header? as yousay it > makes no sense, how to send the PRACK?
Oh, I can see that anytime - in the logs of our server talking to that SIP device :-) That was exactly my point - it's not possible to address PRACK if there's no Contact in 18x. >> We have a long argument with a SIP vendor who insists that Contact >> header is optional in provisional responses - even those that require >> reliable handling, according to rfc3262. But that breaks logic in our >> code where early dialogs set up with reliable provisional responses are >> treated as normal dialogs; as the result the PRACK requests _needs_ to >> be sent as in-dialog request and addressed to the remote peer URI. >> >> We'd rather to avoid creating vendor-specific workarounds in our code, >> as it works with reliable responses sent by other SIP end-points. So, I >> hope to get here some opinion to back up our position in this argument:-) > > The arguments I would tell to that SIP vendor are: > > > RFC 3262: > ------------------------------------------------------ > > 4 UAC Behavior > > The provisional response ***MUST establish a dialog*** if one is not yet > created. > > *** NOTE: And which parameters are needed for creating a dialog? let's > continue reading: > > > > RFC 3261 > ------------------------------------------------------ > > 12 Dialogs > > A dialog contains certain pieces of state needed for further message > transmissions within the dialog. This state consists of the dialog > ID, a local sequence number (used to order requests from the UA to > its peer), a remote sequence number (used to order requests from its > peer to the UA), a local URI, a remote URI, ***remote target***, a boolean > flag called "secure", and a route set > > ***NOTE: About the "remote target" see later section "12.1.2 UAC Behavior" > > > 12.1 Creation of a Dialog > > Dialogs are created through the generation of non-failure responses > to requests with specific methods. Within this specification, only > 2xx and 101-199 responses with a To tag, where the request was > INVITE, will establish a dialog. > > *** NOTE: a 101-199 response creates a dialog (early-dialog) if it includes a > Contact. > > > 12.1.1 UAS behavior > > When a UAS responds to a request with a response that establishes a > dialog (such as a 2xx to INVITE) [...] > The UAS ***MUST add a Contact*** header field to > the response. The Contact header field contains an address where the > UAS would like to be contacted for subsequent requests in the dialog > > *** NOTE: "such a 2xx" doesn't mean that *just* a 2xx. 1xx with Contactalso > creates a dialog (early-dialog) if it has Contact. > > > 12.1.2 UAC Behavior > > The ***remote target*** MUST be set to the URI > from the Contact header field of the response. > > ***NOTE: So, to create a dialog we need the remote target that is equalto the > Contact in the dialog establishing response. > > > 12.2.1 UAC Behavior > 12.2.1.1 Generating the Request > > The UAC uses the remote target and route set to build the Request-URI > and Route header field of the request. > > --------------------------------- Yes, the above is pretty much in line with the arguments we presented to that vendor, but ... > In conclusion: > > RFC 3262 says clearly that "The provisional response ***MUST establish a > dialog*** if one is not yet created". ... they just refer to the fact that Tables 1 and 2 in rfc3262 extend tables 2 and 3 in rfc3261 and the Contact is marked as optional in 1xx responses. If 3262 clearly stated that reliable provisional responses MUST have Contact - we would not have this issue. > RFC 3261 says clearly (not so clearly unfortunatelly) that a dialog must > contain a remote target for the UAC that is set to the Contact in the UAS > response. Also is says that an in-dialog request must have the RURI setto > the remote target, and since PRACK is an in-dialog request it needs the > remote target (this is, the Contact in the 1xx response). > > I think that with the above extracts it's competely clear that Contact is > needed in a response requiring "100rel". I wholeheartedly agree with you. Thank you very much for this complete collection of references to rfc documents. Yet, how simpler the life would be if rfc3262 (at least) stated clearly that with reliable provisional responses the Contact header is required :-) > Hope it helps. Yes, it does. Thank you! -- Best regards, Dmitry Akindinov -- Stalker Labs. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
