Hi, >I would then propose that we say that a proxy SHOULD drop >unreliable 199 responses which are sent out-of-dialog. > >If the 199 response is sent reliably, I don't think we can drop it. > >[Tan] 199 response sent reliably out-of-dialog are still illegal 199. >If the proxy can't drop it, does it create a new dialog with >its new To tag like any non-100 responses ? Do we forward such reliable 199 >responses to UAC which did not indicate support of 199 just >because you think that we cannot drop reliable 1xx. If yes, such reliable but >illegal 199 responses will create new early dialogs at UAC. >Even if the UAC has indicated support of 199, should the reception of >out-of-dialog 199 by UAC create a new early dialog ?
Even if the proxy recieves the 199 out-if-dialog, the UAS may actually have sent it in-dialog, before the final response was sent. The 199 and the final response then "crossed each other" on the link, so that the proxy recieves the 199 before the final response. So, if the 199 is sent reliably, in-dialog, the UAS may have a state machine re-transmitting it until it receives a PRACK. Therefor I don't think the proxy can drop it. And, since other proxies upstream have already received the final response, I don't think they will reserve any resources when they receive the 199. Exactly the same thing can happen with any reliable provisional response. And, if proxies receive 199 out-of-dialog, without any associated INVITE transaction, they are not going to reserve any resources. >>and RFC3261/13.2.2.4: >> >>The UAC core considers the INVITE transaction completed >>64*T1 seconds after the reception of the first 2xx response. >>At this point all the early dialogs that have not transitioned to established >>dialogs are terminated. Once the INVITE transaction is considered completed by >>the UAC core, no more new 2xx responses are expected to arrive. > >Implementations will normally terminate all other early >dialogs when the >first 2xx is recevied. Then, if additional 2xx response (on other >dialogs) are received, implementations will normally send ACK+BYE for >them. So, yes, the INVITE transaction is still alive, but the early >dialogs are normally terminated. > >[Tan] The RFC has to be able to stand by itself and not be >dependant on what implementations would normally do. Yes. I have now added some text. Regards, Christer _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [email protected] for questions on current sip Use [email protected] for new developments on the application of sip
