More info inline.
Paul
Paul Kyzivat wrote:
inline
Miguel Garcia wrote:
In the file transfer draft, the current a=file-transfer attribute is
used to indicate to the remote endpoint whether a new file transfer
is requested or not. This allows to keep the file description without
provoking a new file transfer, if, for example, the SDP is repeated
(imagine, due to session timer re-invite).
The problem is: in order to keep the existing ongoing file transfer,
the SDP creator has to change the SDP and set a=file-transfer to
"existing". This is a fragile mechanism: if the application just
ships the last SDP without any changes, then it will provoke a
restart of the file, due to the presence of a=file-transfer:new.
Ideally we would like a mechanism so that, in case the application
repeats the SDP, nothing happens, i.e., if the file transfer is still
going on, remains. If it is concluded, it is not restarted.
This was a major concern of mine when discussing comedia.
I tried very hard to come up with a mechanism that had this property.
But in the end I was unsuccessful. What is proposed here is what was
used in comedia.
I will have to dig back through all the discussion of comedia to
discover what the major impediments were to a mechanism with this
property. I just don't remember any longer.
I went digging in my archives. I came up with two messages on the
subject. One is in the official archives:
http://www1.ietf.org/mail-archive/web/mmusic/current/msg02686.html
The other was private between me and gonzalo. I'm attaching a copy. This
one eventually led to what was adopted, but I don't have any more
discussion on the topic.
Jonathan suggested to use a transfer identifier instead. This looks
interesting: When the endpoint repeats the SDP, if a transfer is
still taking place, it continues. If it already concluded, nothing
happens. If it is a new identifier, it will start at this point.
I'm quite sure we investigated mechanisms like this for comedia and
found them problematic for some reason. Perhaps Gonzalo remembers - he
was the other person involved in that I think.
draft-ietf-mmusic-sdp-comedia-08 used an a=connid attribute with a
token, which I presume is similar to what Jonathan is suggesting.
In any case, as is often the case with o/a issues, 3pcc scenarios broke
this mechanism.
Paul
I propose to replace the current file-transfer attribute with a
file-transfer-id attribute, according to Jonathan's suggestions.
/Miguel
------------------------------------------------------------------------
Subject:
comedia connid
From:
Paul Kyzivat <pkyzivat at cisco.com>
Date:
Tue, 03 Aug 2004 12:03:16 -0400
To:
gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>
To:
gonzalo Camarillo <Gonzalo.Camarillo at ericsson.com>
Gonzalo,
I thought about this some more while sleeping. I agree the problem
cannot be fixed to achieve the goal I was trying to achieve. In
retrospect, there are other cases where it can't be achieved. For
instance, there is a similar situation with preconditions, where after
one offer/answer cycle, the next offer is dependent on something in the
previous answer.
So I think the best we can hope for is a weaker condition - that at the
end of one offer/answer cycle it is possible to compute what the next
offer should be in order to preserve the status quo. Then that only need
be changed if change is subsequently required.
Having said that, if that is the goal, then I think we can do
considerably better than the current proposal for connid - something
that is much mor intuitive. I propose we replace connid with:
a=connection: new
or
a=connection: existing
This is very similar to the old proposal of a=reconnect, except for one
small but significant difference - use in the initial offer.
I don't especially like having to weaken the condition for preserving
the status quo, but if one acknowledges the need to do so I think this
change is an improvement.
Paul
------------------------------------------------------------------------
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic