2009/8/31 Stefan Sayer <stefan.sa...@iptego.de>: >> 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.
Ok, thanks. >> 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. With "propietary" I mean that nobody uses it to inform about a conference. If a vendor decides to use it for conference it would be a "propietary" usage since no RFC specifies it for this purpose (too much generic purpose as 50% of SIP specifications or half-specifications). >> 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. Because most of the providers and vendor focus on voip rather than other cool features :( >> 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. Yes, but please understand my question. I just wanted to know if what I ask is *really specified* in RFC's (something more specific that the generic attributes you suggest above). I know that, even if the specifications were exist, nobody implements them right now. But at least, if they exist and some vendor/provider want to implement such features it doesn't need to implement "propietary specifications". > 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. So that would mean proprietary mechanisms, :( > 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. I don't know why. Skype does implement voice conferences in a very fashion way, with no web interface. I don't understand why SIP world couldn't offer the same based on real standards. Thanks for your comment. -- Iñaki Baz Castillo <i...@aliax.net> _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
