[comments inline] Senthil K Kumar
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, September 02, 2002 8:29 PM To: [EMAIL PROTECTED] Subject: [Sip-implementors] Clarifications regarding SDP "o=" line Hi all, Wanted a couple of clarifications regarding the handling of the SDP origin line vis-a-vis offer/answer. Tried going through the offer/answer and the call-flows draft, but could not solve all of them. 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.] 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.] 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 ] 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.] Thanks in advance. Siddharth. ----------------- Siddharth Toshniwal @ Hughes Software Systems http://www.hssworld.com _______________________________________________ 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
