The only thing that looks pretty firm: MIME isn't the way to go.
On Sep 22, 2008, at 11:26 PM, Dean Willis wrote:
On Sep 22, 2008, at 4:11 AM, Sedlacek Ivo wrote:Hello Eric, thanks for your mail. > What precisely is the use case behind your request?The use case is to initiate sharing of a resource (stored at an external server) to participants of a tightly coupled conference (RFC4353).I've been pondering this. Let me see if I can restate your use case.A number of users are participating in a bridged conference. There is a persistent SIP-initiated session between each UA and the conference bridge.One user wishes to command the conference bridge to retrieve a media sample and play it into the conference.This "paying" operation does not change the session description for any of the existing sessions; rather it results in the delivery of specific media on the existing sessions to the end users.One might envision any sort of control interface to the bridge. It might, for example, have a web-service interface. It might have an RTSP interface. One of the tricky bits of such an interface is correlating the SIP session that is to "hear" the media with the command protocol. For example, how in RTSP does one say "Play this media file onto the conference with Alice, Bob, and Charlie, but not any other conferences".But if the command interface is coaxial with a SIP dialog that supports a session, then we don;t have this correlation problem.Something like an INFO package that has the semantic "Play the media reference by this INFO onto the session containing the INFO" might be appropriate. This is something like "render-to-this-session", as opposed to "render-to-the-user".-- Dean
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
