> Logically there are only a couple of meaningful > alternatives: > > - the *first* 1xx response with a given to-tag > establishes an early dialog, and so it MUST > contain a Contact > > - the first 1xx response with a given to-tag > *and* a Contact establishes an early dialog. > Any 1xx responses with to-tag that *don't* > have a contact are not dialog-establishing. > > - the first 1xx response with a given to-tag > establishes an early dialog even if it doesn't > contain a Contact. In that case, the dialog > is "established, but incomplete". > > Of the above, the last is useless and so should > not be discarded. > > Either of the others is workable. In practice, > an implementor should no doubt support the second > of those on receipt. So the only real question > is whether it is legal to send a first 1xx response > with to-tag that doesn't contain a contact. I > don't have a strong opinion on that.
Unless something like rfc3262 is used, the UAS does not know if the intended dialog establishing 1xx was received and processed first. Thus unless something like rfc3262 is used, the UAC and UAS might not agree upon which 1xx was the dialog establishing response. Per RFC 3261 section 12.1, the To tag within 101-299 response (to dialog creating request) creates the dialog. If the required Contact is missing, it is a malformed message. At this point, the UAC does not know why malformed: 1) first 1xx dropped, 2) pre-rfc3261 implementation, 3) bad implementation, or 4) locally forgotten early dialog. In general, the topic is irrelevant since it is easy for UAS to include Record-Route and Contact within subsequent 1xx for interop reasons (dropped packets, early dialog forgotten, etcetera). However there are situations where a proxy is tempted (181) or needs (199) to take another's To tag. Such situations require the implementers to fully understand what the rfc3261 says or tried to say. Hopefully the topic can get adequately resolved. Concerning 199, draft-ietf-sip-199 can be updated to clearly discuss the topic. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
