XSF logo XSF Discussion - 2013-05-06

  1. Neustradamus has left
  2. stpeter has joined
  3. Jef has left
  4. Jef has joined
  5. Lance has joined
  6. Jef has left
  7. stpeter has left
  8. Lance has left
  9. bear has joined
  10. J.T has joined
  11. J.T has left
  12. bear has left
  13. bear has joined
  14. bear has left
  15. Alex has joined
  16. Nÿco has joined
  17. Nÿco has left
  18. Neustradamus has joined
  19. Neustradamus has left
  20. Neustradamus has joined
  21. jabberjocke has joined
  22. jabberjocke has left
  23. jabberjocke has joined
  24. jabberjocke has left
  25. Nÿco has joined
  26. Nÿco has left
  27. kevin has joined
  28. kevin has left
  29. kevin has joined
  30. kevin has left
  31. jabberjocke has left
  32. jabberjocke has joined
  33. kevin has joined
  34. jabberjocke has left
  35. kevin has left
  36. stpeter has joined
  37. kevin has joined
  38. Alex has left
  39. Ashley has joined
  40. Lance has joined
  41. Ashley has left
  42. Lance has left
  43. Lance has joined
  44. Lance has joined
  45. stpeter has left
  46. stpeter has joined
  47. Lance has joined
  48. Lloyd has joined
  49. jabberjocke has joined
  50. Lloyd has left
  51. Neustradamus has joined
  52. jabberjocke has joined
  53. Lance was there any consensus at the last summit about how to go about dealing with jingle and webrtc? i dont remember
  54. Lance i'm remaking conversat.io using stanza.io instead of socket.io, and im at the point of having to parse and translate SDP. ick
  55. Neustradamus has joined
  56. Neustradamus has joined
  57. stpeter ah
  58. stpeter Lance: interesting topic
  59. stpeter Lance: there are several possible approaches
  60. stpeter (1) Jingle as-is, with server-side gateway or translation to SDP
  61. stpeter (2) a new content-type that would allow us to place SDP directly into a Jingle message (instead of the current payload types)
  62. stpeter (3) SIP/SDP over XMPP, a.k.a. SOX (where the SIP headers are probably minimal, what we care about is the SDP)
  63. Lance has left
  64. Lance has joined
  65. Lance I'd prefer #2, except SDP combines the content and transport description, so we wouldn't be able to use the normal jingle pattern
  66. stpeter right
  67. stpeter it gets ugly
  68. Lance #1 isn't bad IF you have access to the raw data
  69. stpeter no matter which way you go
  70. Lance but the browser doesn't expose that
  71. Lance i'm probably just going to parse the stuff myself and do the translation
  72. stpeter I lean toward #3 despite the fact that it's perhaps the ugliest of the bunch, because I think it would work in all cases (just use XMPP as the transport layer for SIP/SDP)
  73. Lance true
  74. Lance but ugh, so ugly
  75. stpeter yeah
  76. stpeter believe me, I know
  77. Lance and then we're going to want to do data channels over webrtc
  78. Lance so jingle file transfers will have the same problem/solution
  79. stpeter data channels as in screen sharing and the like?
  80. Lance as in sharing raw data
  81. stpeter ah
  82. stpeter ok
  83. stpeter bytestreamy things
  84. Lance you can already do screen sharing via video
  85. stpeter yes
  86. Lance so if we go with SOX to solve the video problem for now, we've doomed jingle to obsolescence
  87. stpeter pretty much, yes :(
  88. stpeter which is why I haven't written it up for general consumption yet
  89. stpeter on the other hand, you can't exactly say that Jingle has taken the world by storm
  90. stpeter and everyone has moved to using SDP, despite the fact that it's icky
  91. stpeter in WebRTC etc.
  92. stpeter so the question is, what do we do?
  93. stpeter server-side gateways and translators have their own challenges
  94. stpeter with state management and such
  95. stpeter so that leaves us with <jingle> wrappers around SDP, or SoX
  96. stpeter #2 does away with most of what is good about Jingle (separation of description from transport)
  97. stpeter and leaves only the barest of the state machine
  98. stpeter and that state machine might not even really apply very well if the payload of the <jingle/> element is SDP
  99. stpeter I haven't worked out that model, but it worries me a bit
  100. stpeter I grant that SOX is utterly ugly, but it's pragmatic
  101. stpeter shrugs
  102. Lance at this point, minting a <sdp /> element sounds reasonable. and just iq set back and forth, leaving the state management to whatever SDP processor is in use
  103. Lance which is pretty much exactly the pattern in use for webrtc
  104. stpeter I lean toward <message/> so it can be forked if needed, but right
  105. stpeter IMHO we might need or want to include some minimal SIP headers (e.g., if there's a gateway or translator in the middle it can add a Via header)
  106. stpeter but the SIP headers would pretty much be dummied up
  107. Lance would that really be needed in the content going over xmpp? not added by the receiver?
  108. stpeter I grant that we might want separate <sip/> and <sdp/> elements under the <sox/> element
  109. Lance or
  110. Lance use shim
  111. Neustradamus has joined
  112. stpeter well, if we look at SOX as a pure tunneling solution then yes, I think we'd want both SIP and SDP in there
  113. stpeter I freely grant that it's even uglier than sending plain SDP :P
  114. stpeter I need to think about it a bit more
  115. Lance maybe, but it's already there. depends on how many headers you expect to be adding
  116. Lance ^ referring to shim
  117. stpeter ah
  118. stpeter I admit that I haven't thought about using SHIM here
  119. Lance I think I'd prefer it, just to keep the sip an extra arm length's away
  120. stpeter heehee
  121. stpeter in practice, do folks have a standalone SDP library to call, or would they just hand the SIP/SDP off to an RTC library of some kind?
  122. Lance that's what i'm looking up now
  123. stpeter GMTA!
  124. stpeter my sense has been the latter
  125. stpeter but I haven't researched it
  126. Lance not seeing anything noteworthy in python to process SDP
  127. Lance maybe gstreamer
  128. stpeter yeah
  129. stpeter I think most libs bundle SIP and SDP together
  130. Lance yep
  131. stpeter that's what I saw and heard
  132. stpeter which also has led me down the SoX road
  133. stpeter the SoX road is paved with good intentions :-)
  134. Lance certainly
  135. stpeter unfortunately we know where such roads lead ;-)
  136. Lance but it's just a short step to it being SIMPLEoX
  137. stpeter no!
  138. stpeter I disagree
  139. stpeter SoX for audio/video and XMPP for everything else - messaging, presence, etc.
  140. Lance if we can keep it constrained to that, then great
  141. stpeter and that's if you have an XMPP-only endpoint
  142. Lance i just have nightmares of, we're already including these sip headers, just add this other one
  143. stpeter I see the world going to CUSAX -- combined use of SIP and XMPP, with SIP for audio/video and XMPP for messaging, presence, groupchat, etc. -- that's why I've been working on https://datatracker.ietf.org/doc/draft-ivov-xmpp-cusax/
  144. Alex has joined
  145. stpeter IMHO, SOX is only for XMPP-only endpoints
  146. Lance right
  147. Alex has joined
  148. Neustradamus has joined
  149. stpeter Lance: think about it some more and let me know what conclusions you reach
  150. stpeter Lance: I might need to write up the SoX idea here soon...
  151. Lance stpeter: do you have any examples for what a typical payload would be for sox?
  152. stpeter maybe :-)
  153. stpeter fishes around
  154. stpeter sorry, IRL interrupt
  155. stpeter ok
  156. stpeter where was I? ;-)
  157. stpeter Lance, you'd probably have something like this... <message from='romeo@example.net/orchard' to='juliet@example.com'> <sox xmlns='urn:xmpp:sox:0'> INVITE sip:juliet@example..com sip/2.0 Via: SIP/2.0/tcp example.net;branch=z9hG4bK1602341dcb7 From: <sip:romeo@example.net>;tag=0019 To: <sip:juliet@example.com> Contact: <sip:romeo@example.net>;gr=orchard Call-Info: <xmpp:romeo@example.net>;purpose=impp Call-ID: 0019aa04-50550007-660c7034-529a811b Date: Mon, 6 May 2013 21:27:24 GMT User-Agent: foo CSeq: 101 INVITE Max-Forwards: 70 Expires: 180 Allow: ACK,BYE,CANCEL,INVITE Content-Type: application/sdp Content-Length: nnnn v=0 o=<username> <ntp> <ntp> IN IP4 <client_ip> s=SoX Media Setup c=IN IP4 <client_ip> t=0 0 m=audio 9000 RTP/AVP 105 106 121 a=rtpmap:105 opus/48000/2 a=fmtp:105 maxplaybackrate=16000; sprop-maxcapturerate=16000; maxaveragebitrate=24000; stereo=1; useinbandfec=1; usedtx=0 a=rtpmap:106 iLBC/8000 a=ptime:40 a=maxptime:40 a=recv-source 1,2,3 a=rtpmap:121 mix/90000/1 a=fmtp: 121 105/106 a=sendrecv </sox> </message>
  158. Lance thanks!
  159. stpeter not sure about the SIP and SDP details
  160. stpeter I'll need to review those more carefully
  161. stpeter might need to at least write up a document this evening, for my own thinking if nothing else
  162. stpeter but for now I need to jet home in time for my next conference call
  163. stpeter well, not *literally* jet of course ;-)
  164. Lance have fun!
  165. stpeter always! ;-)
  166. stpeter disappears in a puff of smoke
  167. stpeter has left
  168. Jef has joined
  169. Lance has left