Sidharth, You have found an error in the basic call flows document that I will fix. In Message F10 of flow 3.7, A does change the port, so the version number in the SDP should be incremented. I will make this change to the document. Any time the SDP has changed, the version number should be changed as well.
Also, for questions about SDP and call hold, take a look at the Service Examples draft (http://www.ietf.org/internet-drafts/draft-ietf-sipping-service-examples-02.txt) since it shows (hopefully) the correct behavior in a few flows. Thanks, Alan Johnston sip:[EMAIL PROTECTED] At 02:20 PM 9/4/2002 +0530, [EMAIL PROTECTED] wrote: >Hi Senthil, > >Thanks for your response. Please find my comments inline >with "SID>>" preamble. > >Cheers, >Siddharth. > >----------------- >Siddharth Toshniwal @ Hughes Software Systems >http://www.hssworld.com > > >1. In case the UAC sends SDP in INVITE with the session-id > in the "o=" line as (say) 2845844566, is it a MUST for > the UAS to return the same session-id in the answer? > The offer/answer-02 draft allows the UAS to have an > independant version number, but is silent about the > session-id field. Can the UAS use a different session-id > and use the same session-id henceforth? The call-flows > draft (draft-ietf-sipping-basic-call-flows-00.txt) does > seem to indicate this. > > [ The example on section 10 is an clear indication > that the session ids can be changed. Reason the o= > line needs to be changed.] > >SID>> The example shows this, yes. But the call-flows do >SID>> have an occasional omission/error. So I wanted to >SID>> confirm :) Read on please, and the intent of this >SID>> question will be clearer. > > >2. Same offer, but a different answer > ---------------------------------- > Should the 'version' field of the "o=" line in the answer > be incremented even if the offer was unchanged and the > answer is different from the original answer in > (a) only the ports? > (b) only a change in IP address? > (c) change (addition/subtraction) in accepted codecs? > > [ If I change my SDP I would like to version it to keep > track of recent offer/answer I have made . The answer > is yes, if the answerer decides to give an different > SDP he would have an different version.] > >SID>> Again, if the call-flows are correct, then the version >SID>> need not be incremented for a change in the port number. >SID>> The example that begins on Page 62 of the latest call- >SID>> flows draft (draft-ietf-sipping-basic-call-flows-00.txt) >SID>> seems to indicate that. Please refer to the SDP message >SID>> in the steps F1 and F10 of the call-flow (Section 3.7) >SID>> I mentioned. The user A has changed port of the stream, >SID>> but not updated the version in the SDP. Question arises, >SID>> is this a nit in the call-flow draft or is this the way >SID>> its supposed to be? The rest of my questions above were >SID>> extensions to the doubt. >3. Different offer, but same answer > -------------------------------- > If the offer is different from the previous offer by > the UAC (he's trying to add some codecs, say); but the > answer that the UAS generates is the same as the previous > answer (all additions that were attempted are rejected), > then should the UAS increment its version in the o= line? > If it does, is it an error? > > [ No you have to increment version from the previous version > which has been answered for the previous offer ] > >SID>> Why so? In case the caller wants to put our client on hold, >SID>> and we do not put the caller on hold in turn, then the >SID>> answer involves no change to the session data. In such a >SID>> case is it necessary for the server to increment version? > > >I feel it would be good if the offer/answer draft was >made more explicit regarding the handling of the o= line. > > [ I personally feel RFC 2327 is clear on version usage] > > [<version> is a version number for this announcement. It is needed > for proxy announcements to detect which of several announcements for > the same session is the most recent. Again its usage is up to the > creating tool, so long as <version> is increased when a modification > is made to the session data. Again, it is recommended (but not > mandatory) that an NTP timestamp is used.] > >SID>> What constitutes a change to the "session data" >SID>> is my point. Is it a change in codecs, or a change >SID>> in ports or a change in IP address where the stream >SID>> has to flow? Ideally, it should be any combination of >SID>> the 3, I believe. > > > >_______________________________________________ >Sip-implementors mailing list >[EMAIL PROTECTED] >http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
