(17:51:43) Robot101: ping
(17:51:48) Peter Saint-Andre: howdy
(17:51:54) Robot101: bad news on the jingle front
(17:51:57) Peter Saint-Andre: oh
(17:52:13) Robot101: I was just reviewing some patches on our streaming component, and we all had a big "oh shit" moment
(17:52:18) Peter Saint-Andre: heh
(17:52:24) Peter Saint-Andre: better now than later
(17:53:33) Robot101: we had a conf call a few weeks ago where we decided the API of our streaming library didn't need to represent stream directionality changing, because in ICE there's no difference between a unidirectional and a bidirectional stream, and in other lesser protocols you can't change directionality, you just have to add streams going the other way
(17:54:30) Robot101: unfortunately we incorrectly assumed this meant we'd be able to just send or not send RTP to choose whether or not the other end saw a video window or not
(17:54:57) Robot101: but this isn't actually sufficient to distinguish between intentionally not sending video, putting the other person on hold, or just a bunch of packet loss
(17:55:07) Peter Saint-Andre: ah
(17:56:25) Robot101: so we actually need a way to indicate and change content directionality in the signalling :(
(17:56:27) Peter Saint-Andre: yeah, that makes sense
(17:56:35) Robot101: SIP has this but we didn't actually realise
(17:58:01) Robot101: we had a ponder and thought that the directionality might also effect the transport layer
(17:58:11) Robot101: in ICE you always send bidirectional STUN so there's no difference
(17:58:22) Robot101: but for something simpler like a UDP stream, it would effect listening or not
(17:59:05) Robot101: (should we get a MUC or an IRC channel with logs posted somewhere, for our jingle spec discussions?)
(17:59:43) Peter Saint-Andre: well my client is logging this discussion :-)
(18:00:43) Robot101: mine too, but it's hardly transparent :)
(18:00:46) Robot101: anyway
(18:01:13) Robot101: the upshot of this is that the directionality needs to be outside of the content description, because it effects the transport too
(18:01:27) Peter Saint-Andre: oh hrm
(18:01:46) Robot101: so we wondered about making it an attribute on the <content>
(18:02:27) Robot101: then a brief sideline into <content direction="from/to/both"> and how this would mean that people would have to flip the direction every time they acknowledged something
(18:02:36) Peter Saint-Andre: hrm yea
(18:02:43) Robot101: versus maybe <content sender="initiator|peer|both">
(18:02:54) Peter Saint-Andre: I think that's better
(18:03:02) Peter Saint-Andre: from and to cause endless confusion
(18:03:21) Peter Saint-Andre: we have that in presence subscriptions, no need to duplicate it here
(18:06:43) Robot101: so for the bad-hair use case, you could change a call from bidir to unidir before accepting it
(18:07:00) Robot101: slight proviso that we don't have a session-modify action
(18:08:13) Peter Saint-Andre: I thought we did
(18:08:15) Peter Saint-Andre: but I see not
(18:08:21) Peter Saint-Andre: so we need that
(18:10:36) Robot101: then the bad hair use-case becomes:
A->B:
<jingle action='session-initiate'>
<content name='audio'> (I guess we default to both?)
<desc...><transport...>
</content>
<content name='video'>
<desc...><transport...>
</content>
</jingle>
(B->A: ack)
B->A:
<jingle action='session-modify'>
<content name='video' sender='initiator' />
</jingle>
(A->B: ack)
B->A:
<jingle action='session-accept'>
(18:12:24) Peter Saint-Andre: yes
(18:12:29) Peter Saint-Andre: and I think default to both is good
(18:13:27) Robot101: then once you've combed your hair, you can modify it to sender='both' :)
(18:13:34) Peter Saint-Andre: heehee
(18:15:51) Peter Saint-Andre: ok
(18:17:43) Robot101: ok so hopefully that doesn't complicate anything too much
(18:17:49) Peter Saint-Andre: no I don't think so