Hello, Iñaki Baz Castillo wrote: > 2008/10/2, Dmitry Akindinov <[EMAIL PROTECTED]>: >>> For me this means that, in RFC 3261, Contact must be present in a 2xx >>> to an INVITE. >>> >> Yes, but according to this table it's optional for 1xx. And 3262 does not >> update that, though with reliable 1xx the Contact is more likely to be >> needed to address the PRACK. > > Yes, but RFc3261 updates the 1xx behaviour when it clearly says: > > RFC 3262: > ------------------------------------------------------ > > 4 UAC Behavior > > The provisional response ***MUST establish a dialog*** if one is not yet > created. > ------------------------------------------------------- > > And note that for a dialog to be established it's needed a remote > target (not the initial RURI).
Yes, this is exactly how we get the idea of SIP dialogs, including the early ones. And that's why we want to avoid programming workarounds in our code particularly for this situation - because we believe that a 1xx without the Contact URI but requesting reliable handling is wrong. It's also not right even when reliable handling is not requested, but that does not hit us that bad :-) > So, it's true that RFC 3262 doesn't update the table, but note that > "Contact" just would be required if the 1xx includes a "Require: > 100rel", That's something we kept saying to the vendor for several month already. > so there is no need to update that table. In any case RFC > 3262 could add: > > Header field where proxy ACK BYE CAN INV OPT REG > ___________________________________________________________ > Contact R o - - m o o > Contact 1xx - - - o - - > Contact 1xx + 100rel - - - m - - > Contact 2xx - - - m o o > Contact 3xx d - o - o o o > Contact 485 - o - o o o It could, but it does not, unfortunately. > Well, as you say life would be better if RFC 3262 says that, but > however this is implicit by the above phrase "The provisional response > ***MUST establish a dialog*** if one is not yet created". Well, here we have a chain of reasoning (early dialog is created -> PRACK is sent within a dialog -> as an in-dialog request it should be addressed to RURI -> RURI should have been sent with 1xx -> RURI is required) versus the simple and short reference to tables in rfc3262 and 3261 not marking the Contact header as required. And for some it's hard to follow these chains. Thank you very much for your comments. I've sent the link to the list archive with this discussion to the vendor. I hope this will move the scales and they fix their SIP implementation. -- Best regards, Dmitry Akindinov _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
