o Iñaki Baz Castillo [08/31/09 15:45]: > 2009/8/31 Stefan Sayer <stefan.sa...@iptego.de>: >> Hi Iñaki, >> >> o Iñaki Baz Castillo [08/31/09 13:23]: >>> Hi, an existing and very extended privative and diabolic VoIP protocol >>> has a cool feature about voice conference: >>> >>> 1) alice is speaking with bob. >>> 2) alice decide to invite carol to the conference. >>> 3) carol receives a call and shows the number of the participants >>> (alice and bob). >>> >>> With the current SIP conference specifications (which I have not read >>> yet): >>> >>> - Is point 2 possible? This is: creating a conference from a previous >>> user2user normal call. >> alice can set up the conference call and transfer bob and possibly carol >> into the conference. > > Yes, but this is not so useful. In most of the cases the flow is: > > - alice is speaking with bob. > - Later, both realize that carol has been connected (presente status). > - alice wants to invite carol to the *existing* conference. > > This is what people expects instead of having to call first to the > conference server, latter invite bob and carol in other phone line and > transfer them to the conference. of course this is what the phone should do (if it is 'intelligent'), not the user of the phone, who should not have to care what is happening behind the curtains.
> > > >>> - Is point 3 possible? This is: the INVITE carol receives contains >>> info about the current participants and also includes some header or >> I think the idea is to SUBSCRIBE to a conference notification service that >> will give you the list of participants attending, and NOTIFY you in case of >> changes. > > Sorry but I don't understand. How could it be useful? what about > dynamically created conferences? Nobody can expect that carol is when you get the INVITE, you can fetch the status of the dynamically created conference (subscribe with expires 0), display it to your user, and if he wants to accept, subscribe again, for live status of your conference. > always subscribed to *any* conference. And anyway... does a > "subscription to conference status" exist for SIP? have a look at RFC 4353 and referenced documents. Personal opinion follows below (apologies if too much). >> A much much simpler method for a completely centralized conference: Have the >> SDP contain an u= line (see RFC4566), or the INVITE a Call-Info header (see >> 3261) with the url, and in the client display the conference status and >> control with state of the art web app GUI (not very beautiful example, but >> does have url in SDP: https://webconference.iptel.org ). REFER bob to the >> conference. > > Thanks, but what you suggest seems more a "propietary" implementation > rather than a real standard, so it would require "custom" clients > understanding these parameters in the way you suggest. Also, I expect u= line in SDP is standardized with exactly that meaning since 2327, even though apparently no one uses it in the context of SIP with SDP offer/answer. Call-Info is from RFC3261, and it doesn't seem to me that the usage is proprietary, even though unfortunately no one uses it. > that the days in which all the "cool" SIP features are implemented as > a web are close to dissapear :) and the divide between SIP networks and "innovative/cool services" is getting bigger by the day, indeed. > > The intelligence must be in the endpoints rather than in a web page :) show me a reasonably priced SIP phone that implements all of that conferencing framework (client side), supporting what you asked for above. I think this will not change in the coming years. What we are going to have much earlier is mobile and fixed devices which are much more intelligent: They are able do render complex GUIs in a full web browser, because there is demand and this is commodity technology already. For a conference that is centralized anyway (mixing, policies etc), it would IMO make sense to use the UI techniques and technologies that were developed in the web world in telco world as well, because they are simply much more advanced, interoperable, cheaper (both client and server side), flexible. Stefan _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
