Subject: [MMUSIC] Re: [Simple] MSRP: Some thoughts on session updates

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Jan 2004 10:06:13 -0500

My attempts to reach David Yon at the address he has listed in the 
comedia draft ([email-masked]) have bounced. Does anybody know whether 
he is still at Dialout.Net, or even if Dialout.Net still exists?

	Paul

Paul Kyzivat wrote:
> Ben,
> 
> I'm copying David Yon on this since he is author of comedia. This 
> probably won't make any sense out of context to him, so I will 
> separately send him some of the earlier discussion.
> 
> I don't recall what the current status of comedia is. It is currently 
> listed as a WG draft, but there don't seem to be any goals listed for it.
> 
>     Paul
> 
> Ben Campbell wrote:
> 
>> Paul Kyzivat wrote:
>>
>>>
>>>
>>> Ben Campbell wrote:
>>>
>>>> (More comments on same email...)
>>>>
>>>> Paul Kyzivat wrote:
>>>>
>>>> [...]
>>>>
>>>>>
>>>>> Using the same media lines for the replacement session solves the 
>>>>> association problem for any media type - MSRP, RTP, whatever. But 
>>>>> it also does leave the problem of distinguishing a "reconnect" 
>>>>> offer from a "don't change anything" offer.
>>>>
>>>>
>>>>
>>>>
>>>> Would doing this, plus using the COMEDIA reconnect attribute help? 
>>>> (section 5 of current comedia draft.)
>>>
>>>
>>>
>>>
>>> That would probably work. The feature in comedia didn't end up as I 
>>> hoped it would. While it does mean you have to do something special 
>>> (add the a=reconnect) attribute to cause a reconnect, having done 
>>> that once you then have to do something else (remove the a=reconnect) 
>>> in a subsequent exchange.
>>>
>>> I think it would be better if there were something like 
>>> a=version:nnn, which would just be a version number for a particular 
>>> media session. Then whenever it changes you reconnect. If the 
>>> attribute was absent it could be defaulted from the o-line.
>>
>>
>>
>> I agree that sounds like a better approach. Do you think there is any 
>> chance to convince the COMEDIA folks to follow the same approach?
>>
>>>
>>>     Paul
>>
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: David Yon <[email-masked]>
Date: Mon, 12 Jan 2004 10:51:40 -0500

Here I am!   :-)

Dialout.Net is defunct, but at the moment I am still willing to support the 
comedia draft, although I have much less time available to me for it.

My only concern with a "version" attribute is that it causes a reconnection 
by inference.  I'm afraid that it would be rife with temptation to use it 
to version-stamp the session for other reasons that do not imply the 
impetus to reconnect.  Is there some tangible scenario where "version" is 
superior to "reconnect"?

At 10:06 AM 1/12/2004, Paul Kyzivat wrote:
>My attempts to reach David Yon at the address he has listed in the comedia 
>draft ([email-masked]) have bounced. Does anybody know whether he is 
>still at Dialout.Net, or even if Dialout.Net still exists?
>
>         Paul
>
>Paul Kyzivat wrote:
>>Ben,
>>probably won't make any sense out of context to him, so I will separately 
>>send him some of the earlier discussion.
>>>>>>association problem for any media type - MSRP, RTP, whatever. But it 
>>>>>>also does leave the problem of distinguishing a "reconnect" offer 
>>>>>>from a "don't change anything" offer.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>(add the a=reconnect) attribute to cause a reconnect, having done that 
>>>>once you then have to do something else (remove the a=reconnect) in a 
>>>>subsequent exchange.
>>>>
>>>>I think it would be better if there were something like a=version:nnn, 
>>>>which would just be a version number for a particular media session. 
>>>>Then whenever it changes you reconnect. If the attribute was absent it 
>>>>could be defaulted from the o-line.
>>>
>>>
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Jan 2004 13:14:42 -0500

David Yon wrote:
> Here I am!   :-)
> 
> Dialout.Net is defunct, but at the moment I am still willing to support 
> the comedia draft, although I have much less time available to me for it.

I was suspecting Dialout might be gone because attempts to access the 
web site timed out. Glad to hear that you are still around. Maybe you 
should submit a new version of comedia just to update your address.

> My only concern with a "version" attribute is that it causes a 
> reconnection by inference.  I'm afraid that it would be rife with 
> temptation to use it to version-stamp the session for other reasons that 
> do not imply the impetus to reconnect.  Is there some tangible scenario 
> where "version" is superior to "reconnect"?

I can see how you might consider reconnection by inference to be a 
negative. But in my view that is also its appeal.

The point is to preserve the behavior that reuse of unchanged SDP acts 
as a no-op. Once you introduce the a=reconnect attribute, a subsequent 
offer/answer cycle that reuses sdp containing that will cause another 
reconnect, which isn't a no-op.

By using a=version, it is the detection of a revised version number that 
causes the reconnect. So a subsequent offer/answer cycle using the same 
sdp will not see a change in version number and so will not cause 
another reconnect.

This is of significance whenever there might be components that 
manipulate offers and answers in a generic way. For instance, if you 
have a UA that manages multiple media streams, there may be one 
component that decomposes the sdp and then interacts with a separate 
component in the UA for each stream. If there is a need to make a change 
in one stream, it may simply want to make a change in the description of 
the affected stream without dealing with the components responsible for 
other streams. In general, with the exception of a=reconnect, it can do 
this.

I am not especially attached to the name "version". I am certainly 
willing to entertain some other name for the attribute that is clearer 
and less prone to invite abuse. E.g. we might consider a=reconnect:NNN.

	Paul

>> comedia draft ([email-masked]) have bounced. Does anybody know 
>> whether he is still at Dialout.Net, or even if Dialout.Net still exists?
>>
>>         Paul
>>
>> Paul Kyzivat wrote:
>>
>>> Ben,
>>>>> that once you then have to do something else (remove the 
>>>>> a=reconnect) in a subsequent exchange.
>>>>>
>>>>> a=version:nnn, which would just be a version number for a 
>>>>> particular media session. Then whenever it changes you reconnect. 
>>>>> If the attribute was absent it could be defaulted from the o-line.
>>>>
>>>>
>>>>
>>>>
>>>> I agree that sounds like a better approach. Do you think there is 
>>>> any chance to convince the COMEDIA folks to follow the same approach?
>>>>
>>>>>
>>>>>     Paul
>>>>
>>>

---

From: David Yon <[email-masked]>
Date: Mon, 12 Jan 2004 14:48:29 -0500

At 01:14 PM 1/12/2004, Paul Kyzivat wrote:

>I was suspecting Dialout might be gone because attempts to access the web 
>site timed out. Glad to hear that you are still around. Maybe you should 
>submit a new version of comedia just to update your address.

Yeah, I was waiting for other excuses to freshen comedia, but there are a 
couple of issues that have kept it deadlocked.  While not all issues for an 
upcoming comedia-06 have been resolved, it would probably be worthwhile to 
spin it just to get discussion going again, even if there are known flaws.

>The point is to preserve the behavior that reuse of unchanged SDP acts as 
>a no-op. Once you introduce the a=reconnect attribute, a subsequent 
>sdp will not see a change in version number and so will not cause another 
>reconnect.
>
>This is of significance whenever there might be components that manipulate 
>offers and answers in a generic way. For instance, if you have a UA that 
>manages multiple media streams, there may be one component that decomposes 
>the sdp and then interacts with a separate component in the UA for each 
>stream. If there is a need to make a change in one stream, it may simply 
>want to make a change in the description of the affected stream without 
>dealing with the components responsible for other streams. In general, 
>with the exception of a=reconnect, it can do this.
>
>I am not especially attached to the name "version". I am certainly willing 
>to entertain some other name for the attribute that is clearer and less 
>prone to invite abuse. E.g. we might consider a=reconnect:NNN.

"reconnect:NNN" would probably be a useful enhancement to "reconnect", and 
if connection reestablishment was the goal of "version", then I would vote 
for that.

The only issue would be that of the original SDP exchange.  It hardly seems 
appropriate to include a "reconnect" attribute in the initial exchange, but 
then when you want to negotiate a new connection and suddenly this 
attribute appears, what's the appropriate value for NNN?  A couple of 
possibilities:

a) Don't worry about "a=reconnect:0" being an odd inclusion, and make it 
mandatory.

b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0".  Therefore 
the first reconnection negotiation would have "a=reconnect:1".

c) Make the omission imply "a=reconnect:<null>", such that the first 
appearance of "reconnect" would be "a=reconnect:0".

I would guess that (a) makes the most sense.  Thoughts?

Also, are there any possibilities of race conditions where the NNN would 
get out of sync between the two endpoints?  If so, how would that be 
resolved?

What about the additional state that must be tracked (the reconnection 
number)?  I don't think that comedia-05 represents any additional state 
over connectionless media, which wouldn't be true for "reconnect:NNN".

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Jan 2004 15:38:29 -0500

David Yon wrote:
> 
> "reconnect:NNN" would probably be a useful enhancement to "reconnect", 
> and if connection reestablishment was the goal of "version", then I 
> would vote for that.

That is certainly the driving force behind it at the moment.
Unless someone can envision another use then I am happy to go along with 
this.

> The only issue would be that of the original SDP exchange.  It hardly 
> seems appropriate to include a "reconnect" attribute in the initial 
> exchange, but then when you want to negotiate a new connection and 
> suddenly this attribute appears, what's the appropriate value for NNN?  
> A couple of possibilities:
> 
> b) Make the omission of "a=reconnect:NNN" imply "a=reconnect:0".  
> Therefore the first reconnection negotiation would have "a=reconnect:1".
> 

That seems reasonable.

In practice the number doesn't mean much except that it change. It would 
work as well if it were an opaque token.

When considered as a version number it makes more sense as an increasing 
number.

How about a=connection:NNN? (With a default of 1.) This numbers the 
connections used to convey the media stream. This is clearly associated 
with connections, so it isn't prone to abuse, and it also conveys a 
clear semantic for the number.

> get out of sync between the two endpoints?  If so, how would that be 

I don't believe there are any race conditions, though there is always 
the possibility of buggy endpoint getting confused.

I don't think there are any race conditions because NNN isn't negotiated 
- it is always managed by one end and conveyed to the other end. In an 
offer/answer exchange, each side could conceivably provide its own value 
for a=reconnect:NNN. It is only meaningful when provided by a passive 
end to an active end, because it determines whether the active end 
should reconnect.

In the case of MSRP, there is only one connection, so reconnection only 
makes sense in the direction of the original connection.

In the case of comedia there could conceivably be two connections, one 
in each direction. If so, it is conceivable that an offer/answer 
exchange could have a=reconnect=NNN going both ways, and resulting in 
zero, one, or two reconnections.

> over connectionless media, which wouldn't be true for "reconnect:NNN".

There is extra implicit state in comedia. It must remember active, 
passive, or both, whether still listening if passive, whether connected 
if active, and ultimately the connection itself must be remembered as 
state. This adds a number that must be associated with the connection. 
Doesn't seem like a big burden.

>>>>> I don't recall what the current status of comedia is. It is 
>>>>> currently listed as a WG draft, but there don't seem to be any 
>>>>> goals listed for it.
>>>>>     Paul
>>>>> Ben Campbell wrote:
>>>>>
>>>>>> Paul Kyzivat wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Ben Campbell wrote:
>>>>>>>
>>>>>>>>> Using the same media lines for the replacement session solves 
>>>>>>>>> the association problem for any media type - MSRP, RTP, 
>>>>>>>>> whatever. But it also does leave the problem of distinguishing 
>>>>>>>>> a "reconnect" offer from a "don't change anything" offer.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Would doing this, plus using the COMEDIA reconnect attribute 
>>>>>>>> help? (section 5 of current comedia draft.)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> That would probably work. The feature in comedia didn't end up as 
>>>>>>> I hoped it would. While it does mean you have to do something 
>>>>>>> special (add the a=reconnect) attribute to cause a reconnect, 
>>>>>>> having done that once you then have to do something else (remove 
>>>>>>> the a=reconnect) in a subsequent exchange.
>>>>>>>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 Jan 2004 13:25:58 -0600

I am fond of the choice of "connection:xx" if we are going to include it 
in the initial SDP--simply because it does not offer quite as much 
cognitive dissonance as discovering a "reconnect:xx" when one has not 
yet connected for the first time.

Paul Kyzivat wrote:

>> suddenly this attribute appears, what's the appropriate value for 
>> NNN?  A couple of possibilities:
>>
>> a) Don't worry about "a=reconnect:0" being an odd inclusion, and make 
>> it mandatory.
>>
>> Also, are there any possibilities of race conditions where the NNN 
>> would get out of sync between the two endpoints?  If so, how would 
>> that be resolved?
> 
> 
>> number)?  I don't think that comedia-05 represents any additional 
>> state over connectionless media, which wouldn't be true for 
>> "reconnect:NNN".
> 
> 
>>>>>>>> That would probably work. The feature in comedia didn't end up 
>>>>>>>> as I hoped it would. While it does mean you have to do something 
>>>>>>>> particular media session. Then whenever it changes you 
>>>>>>>> reconnect. If the attribute was absent it could be defaulted 
>>>>>>>> from the o-line.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>

---

From: Ben Campbell <[email-masked]>
Date: Fri, 16 Jan 2004 13:41:26 -0600

However, on reflection, I wonder why we would make this a separate 
a-line attribute, rather than a parameter on the direction attribute. 
The whole purpose of the direction attribute is to specify how the 
connection is set up. Indicating a desire for a new connection seems to 
fit well into that purpose.

Ben Campbell wrote:

>>> "reconnect:NNN" would probably be a useful enhancement to 
>>> "reconnect", and if connection reestablishment was the goal of 
>>> "version", then I would vote for that.
>>
>>
>>
>> Unless someone can envision another use then I am happy to go along 
>> with this.
>>
>> In practice the number doesn't mean much except that it change. It 
>> would work as well if it were an opaque token.
>>
>> When considered as a version number it makes more sense as an 
>> increasing number.
>>
>> connections used to convey the media stream. This is clearly 
>> associated with connections, so it isn't prone to abuse, and it also 
>> conveys a clear semantic for the number.
>>
>> I don't think there are any race conditions because NNN isn't 
>> negotiated - it is always managed by one end and conveyed to the other 
>> end. In an offer/answer exchange, each side could conceivably provide 
>> its own value for a=reconnect:NNN. It is only meaningful when provided 
>> by a passive end to an active end, because it determines whether the 
>> active end should reconnect.
>>
>> In the case of MSRP, there is only one connection, so reconnection 
>> only makes sense in the direction of the original connection.
>>
>>> What about the additional state that must be tracked (the 
>>> reconnection number)?  I don't think that comedia-05 represents any 
>>> additional state over connectionless media, which wouldn't be true 
>>> for "reconnect:NNN".
>>
>>
>>
>> passive, or both, whether still listening if passive, whether 
>> connected if active, and ultimately the connection itself must be 
>> remembered as state. This adds a number that must be associated with 
>> the connection. Doesn't seem like a big burden.
>>
>>>>         Paul
>>>>
>>>>>>>>>>> whatever. But it also does leave the problem of 
>>>>>>>>>>> distinguishing a "reconnect" offer from a "don't change 
>>>>>>>>>>> anything" offer.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> as I hoped it would. While it does mean you have to do 
>>>>>>>>> something special (add the a=reconnect) attribute to cause a 
>>>>>>>>> reconnect, having done that once you then have to do something 
>>>>>>>>> else (remove the a=reconnect) in a subsequent exchange.
>>>>>>>>>
>>>>>>>> I agree that sounds like a better approach. Do you think there 
>>>>>>>> is any chance to convince the COMEDIA folks to follow the same 
>>>>>>>> approach?
>>>>>>>>
>>>>>>>>>
>>>>>>>>>     Paul
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Jan 2004 14:06:23 -0500

> fit well into that purpose.

If we use the same semantics as with a=connection:NNN then I am quite 
fine with it being bundled into the direction attribute. We will have to 
find some way to fit in the value NNN and disambiguate it from a timeout 
value. Complicated because I think both are optional.

Or we could make NNN be mandatory. That isn't so annoying in this form.

	Paul

> Ben Campbell wrote:
> 
>> I am fond of the choice of "connection:xx" if we are going to include 
>> it in the initial SDP--simply because it does not offer quite as much 
>>>> The only issue would be that of the original SDP exchange.  It 
>>>> hardly seems appropriate to include a "reconnect" attribute in the 
>>>> initial exchange, but then when you want to negotiate a new 
>>>> connection and suddenly this attribute appears, what's the 
>>>> appropriate value for NNN?  A couple of possibilities:
>>>>
>>>> a) Don't worry about "a=reconnect:0" being an odd inclusion, and 
>>>> make it mandatory.
>>>>
>>> negotiated - it is always managed by one end and conveyed to the 
>>> other end. In an offer/answer exchange, each side could conceivably 
>>> provide its own value for a=reconnect:NNN. It is only meaningful when 
>>> provided by a passive end to an active end, because it determines 
>>> whether the active end should reconnect.
>>>
>>> In the case of comedia there could conceivably be two connections, 
>>> one in each direction. If so, it is conceivable that an offer/answer 
>>>>>>> My attempts to reach David Yon at the address he has listed in 
>>>>>>> the comedia draft ([email-masked]) have bounced. Does anybody 
>>>>>>> know whether he is still at Dialout.Net, or even if Dialout.Net 
>>>>>>> still exists?
>>>>>>>
>>>>>>>         Paul
>>>>>>>
>>>>>>> Paul Kyzivat wrote:
>>>>>>>
>>>>>>>> Ben,
>>>>>>>> I'm copying David Yon on this since he is author of comedia. 
>>>>>>>> This probably won't make any sense out of context to him, so I 
>>>>>>>> will separately send him some of the earlier discussion.
>>>>>>>>>>>> Using the same media lines for the replacement session 
>>>>>>>>>>>> solves the association problem for any media type - MSRP, 
>>>>>>>>>>>> RTP, whatever. But it also does leave the problem of