Hi Paul, >>>Under what circumstances can it not be clear which usage the 199 >>>applies to? AFAIK the 199 should only be used with an INVITE dialog >>>usage, and there can only be one of those per dialog. (We don't allow
>>>early dialogs for other usages.) >> >>I think it's clear that the 199 applies to the invite dialog usage. But, what if there are other usages? You would need to know whether the error response which triggered the 199 also affects >>those usages. >> >>Again, this would only happen if you have established the other usage during the early phase of the invite dialog (which I think is only theoretical). > >OK. I think I see what you are getting at, but it is somewhat obscure. > >Lets suppose for a minute we have an early invite dialog usage, and have another dialog usage sharing the dialog with it. (E.g. maybe we sent a REFER and got a refer subscription going.) [At >this point Robert runs out of the room, screaming.] > >Of course the invite was also forked, and we have another early dialog going as well. > >Now something happens that leads the forking proxy to want to send a 199 response. Because this is a 1xx class response, it must be something that has happened pertaining to the INVITE, since >we now only allow provisionals for INVITE. I guess the question is whether the response that provokes the 199 might *also* imply the termination of the dialog as a whole rather than just the >invite dialog usage. That can only be determined if the actual final response is known, and we have excluded that have we not? We have not excluded it, but we don't mandate it. In Dublin we decided that the 199 draft will not talk about transfering SIP headers, response codes etc in the 199 response - but it won't forbid it either. Then, if someone wants to use 199 e.g. to solve HERFP, he/she will have to separately specify what headers to included. >>>IMO a better rationale here is that the 199 response is not sent reliably, and so isn't obligated to carry the offer. I think the >>>above logic is weaker and questionable - an early dialog can be established >>>without sending a reliable response. And I *think* a 199 can still be used in that case. >>> >>>I guess the UAS is permitted to send a reliable 199, but it would be >>>sufficient to say that it must not do so if that would obligate it to >>>include an offer. Better yet, lets just say that 199 should *never* >>>be sent reliably. >> >>I have no problem saying that. But, again, I don't think there are cases where you would be obligated to include an offer/answer in 199, because you have already sent at least one 18x. >> >>Of course, one use-case is when the UAS first sends a 18x unreliably, and then send a 199 reliably. In this case, if the INVITE didn't contain an offer, the 199 would have to contain one, >>since it's the first RELIABLE provisional response sent. > >Good - you found your own counterexample! DOH! :) Of course, since it is only the UAS which is currently allowed to send 199 reliably, I guess it wouldn't matter even if the UAS inserted an SDP body. But, if there are some entities which don't understand 199, they may look at the SDP and think that the UAS is trying to establish a media path, which is not good. So, either we say that 199 must not (or should not, if there is a future use-case where it would be useful to send it reliably) ne be sent reliably, or we say that 199 should not (or must not) be sent reliably if it is required to carry SDP. 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
