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
