Hi Paul, >I finally got around to this. A few comments: > >Section 1: > > When SIP entities upstream > receive the 2xx final response they will automatically terminate > other associated outstanding early dialogs. > >This isn't always wise. At this point it is still possible to receive >additional 2xx responses. Discarding the early dialog is probably fine >if subsequent 2xx responses with be dealt with by sending BYE. Correct. I can add some text, clarifying that the SIP enitty should still be prepared to receive additional 2xx responses and deal with the accordingly. >Retaining the early dialog isn't useful in that case. But if the UAC is planning >to accept an additional 2xx response and retain the dialog rather than >terminate it, then it should not discard the early dialog upon receipt >of the first 2xx.
I will mention that also. >(Note that sending cancel upon receipt of a 2xx is MUST in 3261, but it >is overridden by a 'Request-Disposition: no-cancel' specified in RFC >3841. Terminating the early dialog at the UAC is also a MUST, but seems >like it is probably an error.) I can mention that RFC 3841 may affect the behavior of entities regarding termination of early dialogs. >Section 4: > >You give examples of kinds of resources that may be freed upon receipt of the 199. But you also hint at a problem: > > If the client is able to associate the 199 response with a specific media stream, > >In many cases it may be hard/impossible to accomplish this. Can you give some plausible examples of cases when this will be possible? Maybe if the media stream is encrypted, and there are some encryption parameters associated with the dialog. I am not an expert on that, though.... Every now and then there have also been discussions of including parameters, which are sent in the media stream, also in SIP messages, so that media streams can be associated with an early dialog. >I don't understand the following: > > The UAC MAY use additional information (for example the final > response which triggered the 199 response) received in the 199 > response when initiating new sessions, if it is possible to avoid the > new session initation request to be rejected. > >I can't parse it into anything meaningful. This is related to the HERFP problem. I has been agreed to not solve that problem in this draft, but it was agreed to add some words about what the information could be used for. >Section 5: When would it be advantageous for the UAS to send a 199? This is one of the issues which was perviously discussed, so I listed the possibility. Francois also had that question, and I am ok with removing it. >Section 6: > >This has MUST strength language. But of course not all proxies will implement this draft if/when it becomes an RFC. Well, the text only applies to proxies supporting the draft, so... >It it expected that this is to be an independent RFC to which support may be claimed? Yes. The idea is NOT to make a normative reference to RFC3261. >Section 8: > > OPEN ISSUE: We need to discuss whether the To tag in the 199 > identifies the dialog that has been terminated, and/or if some > additional information element (e.g. SIP header) can be used, which > would allow to indicate the termination of multiple dialogs in a > single 199 response. > >My preference is to use the To-tag, so that normal dialog matching rules >will apply. We don't need more irregularities to complicate sip stacks. I agree. I am happy to remove the OPEN ISSUE, unless someone else has a different opinion. > OPEN ISSUE: We need to discuss whether, in addition to the dialog > identifier, some additional information (e.g. the non-2xx final > response which triggered the 199 response) should be provided in the > 199 response. > >I think it would be useful to at least acknowledge that a sipfrag can be >carried in the 199, in a similar way to is carried in a refer event >package notification. Would probably be good to state that it SHOULD NOT >be included unless there was an Accept header mentioning the sipfrag >content type in the request. This was discussed based on input from Francois just a few days ago, so please take a look whether you are ok with the outcome of that discussion. We did not discuss the Accept header, though, and I think that is a good point. >Section 9: > > A 199 Early Dialog Terminated provisional response MUST NOT contain a > new SDP offer/answer message body, but the sender of the response MAY > insert a copy of a previously sent offer/answer message body as > otherwise allowed by the offer/answer rules for a provisional > response. > > A forking proxy or a UAS MUST NOT trigger and send a 199 Early Dialog > Terminated provisional response reliably in a situation where a > reliable provisional response is required to contain an SDP offer/ > answer message body, according to [RFC3262] and [RFC3264]. > >These two paragraphs seem to be slightly at odds with one another, >regarding the sending of an answer in a reliable 199. This can be fixed >by changing the 2nd paragraph to only mention "offer", not "answer". Ok >Section 10: > > OPEN ISSUE: We need to discuss whether a proxy should send 199 > reliably at all, since the proxy would have to terminate the > associated PRACK, and support the logic associated with 100rel. If > not sent, how would required 100rel affect the usage of 199? > >IMO it is a bad idea for a proxy to send a reliable 199. The problem is >that you aren't sending the 199 unless there was already an early >dialog. If there was, the proxy is not the second party in that dialog. >The PRACK will be sent to the peer in the dialog, not the proxy. The >proxy has no business terminating and responding to it. Yet the UAS >won't be expecting it. > >So I think it would only be possible to send a reliable 199 as part of >some new dialog terminated by the proxy. But that then means the To-tag >can't be used to indicate which dialog is being terminated. It just >keeps getting more and more complicated. > >And there really isn't any great value in sending this reliably. So >don't do it. I have no problem with that. A UA that doesn't support 199, but has required 100rel, may discard the unreliable 199, but it really doesn't matter. Thank you very much for the comments! 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
