[MMUSIC] SIP/RTSP interworking
steven.d.whitehead@verizon.com Tue, 07 February 2006 14:23 UTC
Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TkU-00045l-OP; Tue, 07 Feb 2006 09:23:18 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1F6TkO-00043V-W7 for mmusic@megatron.ietf.org; Tue, 07 Feb 2006 09:23:17 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29121 for <mmusic@ietf.org>; Tue, 7 Feb 2006 09:21:21 -0500 (EST)
From: steven.d.whitehead@verizon.com
Received: from irvmail2.verizon.com ([192.76.80.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1F6Twa-0001cX-Rj for mmusic@ietf.org; Tue, 07 Feb 2006 09:35:52 -0500
Received: from smtpirv2.verizon.com (smtpirv2.verizon.com [138.83.34.66]) by irvmail2.verizon.com (8.13.3/8.13.3) with ESMTP id k17EMhgt022141 for <mmusic@ietf.org>; Tue, 7 Feb 2006 09:22:43 -0500 (EST)
Received: from irvp1cvmma01.vzh.ent.verizon.com (irvp1cvmma01.verizon.com [138.83.34.82]) by smtpirv2.verizon.com (8.13.3/8.13.3) with ESMTP id k17ELXAl028601 for <mmusic@ietf.org>; Tue, 7 Feb 2006 08:21:33 -0600 (CST)
Received: from 138.83.34.22 by irvp1cvmma01.vzh.ent.verizon.com with ESMTP (SMTP Relay); Tue, 07 Feb 2006 09:22:28 -0500
X-Server-Uuid: 33D99CC3-91DD-4C5F-B3C4-DE0A72F86AF5
Received: from dwsmtp01.core.verizon.com (dwsmtp01.verizon.com [138.83.35.62]) by coregate1.verizon.com (8.13.3/8.13.3) with ESMTP id k17EMSrR017826 for <mmusic@ietf.org>; Tue, 7 Feb 2006 08:22:28 -0600 ( CST)
Date: Tue, 07 Feb 2006 09:22:28 -0500
MIME-Version: 1.0
To: mmusic@ietf.org
X-Mailer: Microsoft Outlook v 11.00.6353, MSOC v 2.00.4007.00
Message-ID: <OF4E86336A.63343BF2-ON0525710E.004E3C20@CORE.VERIZON.COM>
X-MIMETrack: Serialize by Router on DWSMTP01/HSVR/Verizon(Release 6.5.4HF453 | August 4, 2005) at 02/07/2006 08:22:28, Serialize complete at 02/07/2006 08:22:28
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-WSS-ID: 6FF672AE67W76349-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.3 (/)
X-Scan-Signature: c5b976cb26c967a52d72d6069c7fc54c
Content-Transfer-Encoding: 7bit
Cc: mmontpetit@motorola.com
Subject: [MMUSIC] SIP/RTSP interworking
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
Sender: mmusic-bounces@ietf.org
Errors-To: mmusic-bounces@ietf.org
I, along with Marie Montpetit, am putting together a draft that aims to address SIP/RTSP interworking. The draft will have two main parts: part 1 discusses the rationale for SIP/RTSP interworking and part 2 enumerates design options for SIP/RTSP interworking. The goal is to get it out in time for discussion at the next IETF meeting. Ultimately, we'd like mmusic (or other appropriate group) to pick up this topic as work item. If you're interested in contributing to the draft, please let me know. Thanks, -Steve -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of mmusic-request@ietf.org Sent: Tuesday, February 07, 2006 8:46 AM To: mmusic@ietf.org Subject: mmusic Digest, Vol 22, Issue 5 Send mmusic mailing list submissions to mmusic@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/mmusic or, via email, send a message with subject or body 'help' to mmusic-request@ietf.org You can reach the person managing the list at mmusic-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of mmusic digest..." Today's Topics: 1. RE: Re: mmusic Digest, Vol 22, Issue 3 (Osher Hmelnizky) 2. Wireless/WiFi Convergence Conference - Paris - France (Chantal Ladouce) 3. Re: Re: mmusic Digest, Vol 22, Issue 3 (Teodora Guenkova-Luy) ---------------------------------------------------------------------- Message: 1 Date: Tue, 7 Feb 2006 09:59:03 +0200 From: "Osher Hmelnizky" <Osher.Hmelnizky@audiocodes.com> Subject: RE: [MMUSIC] Re: mmusic Digest, Vol 22, Issue 3 To: "Robert Hagens" <rhagens@envysion.com>, "Colin Perkins" <csp@csperkins.org>, "Teodora Guenkova-Luy" <teodora.guenkova-luy@uni-ulm.de> Cc: mmusic@ietf.org, Oren Kudovitzky <Orenku@audiocodes.com> Message-ID: <79B4F738DDD4EF4F85A4641A0FE5EFD601C8A085@aclmsg.corp.audiocodes.com> Content-Type: text/plain; charset="us-ascii" Hi, When I'm thinking on the Media server implementation in the IMS architecture, it's clear that most of the SIP devices running over the UDP for call establishment. Most of the xml-types streaming/media controls over the SIP using INFO approaches. I'm not sure that this is a right approach for real time streaming control (explicitly for video). RTSP2 (the last draft) defines RTSP to use TCP as transport protocol. TCP is the right approach for real time streaming control. I adopt SIP/Info streaming control for announcement and recording, but for real time stream control I think it's not enough, because of the big delays when, for example Application Server should be involved in the DTMF detection and creation of the appropriate control to the media server. SIP/MRCP2&RTSP seems me right approach for media server control. SIP for session establishment and MRCP or RTSP for the streaming control and media services. I think it should be one common technique for synchronization between SIP and other protocol like RTSP. It may be done using the SDP(for example SIP/MRCP2). Any thoughts? Kind regards Osher -----Original Message----- From: Robert Hagens [mailto:rhagens@envysion.com] Sent: Monday, February 06, 2006 5:03 PM To: 'Colin Perkins'; 'Teodora Guenkova-Luy' Cc: mmusic@ietf.org; Osher Hmelnizky Subject: RE: [MMUSIC] Re: mmusic Digest, Vol 22, Issue 3 The other non-standard aspect of SIP/RTSP is that there is a good chuck of overlap between SIP and RTSP. If you (for example) negotiate the SDP with SIP, you really don't need to bother with the DESCRIBE and SETUP of RTSP. After the SIP negotiation, you're ready to PLAY. This leads one to question if all of the complexity of RTSP is required in these cases; a simpler version of media control being desirable. Rob -----Original Message----- From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of Colin Perkins Sent: Monday, February 06, 2006 2:57 AM To: Teodora Guenkova-Luy Cc: mmusic@ietf.org; Osher.Hmelnizky@audiocodes.com Subject: Re: [MMUSIC] Re: mmusic Digest, Vol 22, Issue 3 SDP has the concept of "m=control ..." to signal other control sessions. If one were to define how to signal RTSP sessions could be setup using SIP, that would likely be the appropriate way to do it. This subject comes up regularly - maybe it would be appropriate for someone to write a draft fleshing out the details? Colin On 6 Feb 2006, at 09:48, Teodora Guenkova-Luy wrote: > SIP and RTSP are two different sessions. Their frameworks do not > exclude the scenario that both of them shall be synchronised, > however, there is no existing solution on such synchronisation. You > can synchronize SIP and RTSP only at presentation level (i.e. SDP), > like done for SIP and MRCP, as at session level SIP and RTSP are > different instances that are not aware of each other. You could > "misuse" the SDP SIP/MRCP attribute "a=channel:xxx" with your own > parameters for RTSP, or use the SDP "i=" line also with your own > paramentes, or define your own attribute line, e.g. > "a=stacksynch:whatever". However, all these are non-standard > solutions. > KR, > Teodora > > mmusic-request@ietf.org wrote: > >> >> Message: 1 >> Date: Sun, 5 Feb 2006 09:41:06 +0200 >> From: "Osher Hmelnizky" <Osher.Hmelnizky@audiocodes.com> >> Subject: RE: [MMUSIC] Using RTSP with SIP >> To: "Burger, Eric" <eburger@brooktrout.com> >> Cc: mmusic@ietf.org >> Message-ID: >> >> <79B4F738DDD4EF4F85A4641A0FE5EFD601C89990@aclmsg.corp.audiocodes.com> >> Content-Type: text/plain; charset="us-ascii" >> >> Hi, >> >> >> What I'm trying to say is: why can't I use SIP for the call >> establishment and RTSP for the stream control. How can synchronize >> two >> protocols on the MRF side? >> On the client side it is no problem, but server side should be aware >> that two sessions are interconnected to the one specific call. >> >> Such synchronization I saw in the SIP/MRCP draft >> (draft-ietf-speechsc-mrcpv2-09). >> >> >> Thanks a lot >> >> >> Osher >> >> >> ________________________________ >> >> From: Burger, Eric [mailto:eburger@brooktrout.com] Sent: Friday, >> February 03, 2006 4:34 AM >> To: Osher Hmelnizky >> Subject: RE: [MMUSIC] Using RTSP with SIP >> >> >> What are you trying to accomplish? Two sessions are two >> sessions. It >> is either SIP or RTSP. MRCP (not an IETF standard) has two, distinct >> sessions. >> >> >> ________________________________ >> >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf >> Of Osher Hmelnizky >> Sent: Tuesday, January 10, 2006 7:26 AM >> To: mmusic@ietf.org >> Subject: [MMUSIC] Using RTSP with SIP >> >> >> In the last MRCP draft (draft-ietf-speechsc-mrcpv2-09), in order to >> synchronize the SIP and MRCP Sessios, defined >> >> a=channel:xxx >> >> >> as part of application SDP. >> >> >> I'm trying to find out how I can synchronize SIP and RTSP streams >> at the >> Media Server layer without any indication. >> >> >> As a=channel defined at the SDP level can I use this parameter to >> sync >> between SIP and RTSP Streams. >> >> >> Thanks a lot. >> >> >> Osher >> >> >> >> >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: http://www1.ietf.org/pipermail/mmusic/attachments/ >> 20060205/0ce380c0/attachment.htm >> >> ------------------------------ >> >> Message: 2 >> Date: Sun, 5 Feb 2006 08:17:22 -0500 >> From: "Burger, Eric" <eburger@brooktrout.com> >> Subject: RE: [MMUSIC] Using RTSP with SIP >> To: "Osher Hmelnizky" <Osher.Hmelnizky@audiocodes.com> >> Cc: mmusic@ietf.org >> Message-ID: >> <330A23D8336C0346B5C1A5BB196666470228F906@ATLANTIS.Brooktrout.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> That is something totally different and explicitly outside the >> scope of MRCPv2. What you want is something like the mediactrl >> work (not chartered). Search the I-D directory for mediactrl. To >> subscribe, send 'subscribe mediactrl' to >> majordomo@lists.ubiquitysoftware.com >> >> ________________________________________ >> From: Osher Hmelnizky [mailto:Osher.Hmelnizky@audiocodes.com] >> Sent: Sunday, February 05, 2006 2:41 AM >> To: Burger, Eric >> Cc: mmusic@ietf.org >> Subject: RE: [MMUSIC] Using RTSP with SIP >> >> Hi, >> >> What I'm trying to say is: why can't I use SIP for the call >> establishment and RTSP for the stream control. How can synchronize >> two protocols on the MRF side? On the client side it is no >> problem, but server side should be aware that two sessions are >> interconnected to the one specific call. >> Such synchronization I saw in the SIP/MRCP draft (draft-ietf- >> speechsc-mrcpv2-09). >> >> Thanks a lot >> >> Osher >> >> ________________________________________ >> From: Burger, Eric [mailto:eburger@brooktrout.com] Sent: Friday, >> February 03, 2006 4:34 AM >> To: Osher Hmelnizky >> Subject: RE: [MMUSIC] Using RTSP with SIP >> >> What are you trying to accomplish? Two sessions are two >> sessions. It is either SIP or RTSP. MRCP (not an IETF standard) >> has two, distinct sessions. >> >> ________________________________________ >> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >> Behalf Of Osher Hmelnizky >> Sent: Tuesday, January 10, 2006 7:26 AM >> To: mmusic@ietf.org >> Subject: [MMUSIC] Using RTSP with SIP >> >> In the last MRCP draft (draft-ietf-speechsc-mrcpv2-09), in order >> to synchronize the SIP and MRCP Sessios, defined >> a=channel:xxx >> as part of application SDP. >> >> I'm trying to find out how I can synchronize SIP and RTSP streams >> at the Media Server layer without any indication. >> >> As a=channel defined at the SDP level can I use this parameter to >> sync between SIP and RTSP Streams. >> >> Thanks a lot. >> >> Osher >> >> >> >> >> >> >> ------------------------------ >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www1.ietf.org/mailman/listinfo/mmusic >> >> >> End of mmusic Digest, Vol 22, Issue 3 >> ************************************* >> > > -- > ----------------------------------------- > Teodora Guenkova-Luy > > Dept. Distributed Systems, University of Ulm, Oberer Eselsberg, > 89069 Ulm, Germany > > Tel.: +49 (0731) 502-4148 FAX: +49 (0731) 502-4142 > > e-Mail: teodora.guenkova-luy@uni-ulm.de > > Home Page: http://www-vs.informatik.uni-ulm.de/~Guenkova/ > ----------------------------------------- > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www1.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic ------------------------------ Message: 2 Date: Tue, 7 Feb 2006 13:21:32 +0100 From: "Chantal Ladouce" <chantal.ladouce@upperside.fr> Subject: [MMUSIC] Wireless/WiFi Convergence Conference - Paris - France To: <mmusic@ietf.org> Message-ID: <20060207122146.2937B8DCF2@safetwo.sceur.ch> Content-Type: text/plain; charset="us-ascii" UMA how? IMS when? At the 2006 Wireless/WiFi Convergence Conference to be held in Paris on May 16 to May 19, distinguished experts and key players in the convergence field will address technical issues. Carriers like BT, Orange, Vonage (etc) will discuss their commercial experience and technological choices. Get all details at: <http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006intro.ht m> http://www.upperside.fr/wirelessconvergence2006/wwconvergence2006intro.htm -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/mmusic/attachments/20060207/49faad4d/attach ment.htm ------------------------------ Message: 3 Date: Tue, 07 Feb 2006 14:45:08 +0100 From: Teodora Guenkova-Luy <teodora.guenkova-luy@uni-ulm.de> Subject: Re: [MMUSIC] Re: mmusic Digest, Vol 22, Issue 3 To: Osher Hmelnizky <Osher.Hmelnizky@audiocodes.com> Cc: Colin Perkins <csp@csperkins.org>, Oren Kudovitzky <Orenku@audiocodes.com>, mmusic@ietf.org Message-ID: <43E8A464.8040107@uni-ulm.de> Content-Type: text/plain; charset="us-ascii" Dear Osher, I see some problems with your task definition/requirements: 1. For real-time streaming you already have some kind of streaming control through RTCP (see also RFC 3551) 2. As SIP and RTSP are much more complex then the RTCP controls, they should be used only in cases that the application needs to adapt (i.e. to re-negotiate capabilities) and not for permanent monitoring/controls. 3. The classical TCP is not a solution when controlling mobile environments. It can be even an obstacle, when the underlying physical network is not faultless (e.g. thread failures due to carrier disruptions). The better solution is UDP (SIP), however, it is also not a perfect solution. The problem on this place is that the development of real-time applications considers currently only the media alone (i.e. aproaches like FEC, ARQ, etc.), what is not considered till now is that the controls for the real-time media are even more urgent then the media itself. SIP actually also does not provide a complete solution but refers to RFC 2914. So if your media server does not care about the mobility of the clients, you can simplify your task and stick to TCP with both SIP and RTSP. IMHO it is right to use SDP for signalling the association of the control sessions with SIP and RTSP. However, currently SDP does not really provide a specific solution for your problem and probably will not be further enhanced and developed in the future to provide a solution (see draft-ietf-mmusic-sdpng-trans-04). So if you do not care about a standardized solution, but care about the faultlessness of your control signalling in non-mobile environments, you can use combinations of SIP (with TCP), RTSP and SDP and enhance them according to your needs using the respective enhancement mechanisms of these protocols. If you shall care about the clients mobility you have to stick to UDP (as carrier of SIP and RTSP) and ensure its faultlessness with e.g. DiffServ-like mechanisms. KR, Teodora IMHO, SDP is the correct pla Osher Hmelnizky wrote: >Hi, > >When I'm thinking on the Media server implementation in the IMS >architecture, it's clear that most of the SIP devices running over the >UDP for call establishment. Most of the xml-types streaming/media >controls over the SIP using INFO approaches. I'm not sure that this is a >right approach for real time streaming control (explicitly for video). >RTSP2 (the last draft) defines RTSP to use TCP as transport protocol. >TCP is the right approach for real time streaming control. > >I adopt SIP/Info streaming control for announcement and recording, but >for real time stream control I think it's not enough, because of the big >delays when, for example Application Server should be involved in the >DTMF detection and creation of the appropriate control to the media >server. > >SIP/MRCP2&RTSP seems me right approach for media server control. SIP for >session establishment and MRCP or RTSP for the streaming control and >media services. >I think it should be one common technique for synchronization between >SIP and other protocol like RTSP. It may be done using the SDP(for >example SIP/MRCP2). > >Any thoughts? > >Kind regards > >Osher > > >-----Original Message----- >From: Robert Hagens [mailto:rhagens@envysion.com] >Sent: Monday, February 06, 2006 5:03 PM >To: 'Colin Perkins'; 'Teodora Guenkova-Luy' >Cc: mmusic@ietf.org; Osher Hmelnizky >Subject: RE: [MMUSIC] Re: mmusic Digest, Vol 22, Issue 3 > >The other non-standard aspect of SIP/RTSP is that there is a good chuck >of >overlap between SIP and RTSP. If you (for example) negotiate the SDP >with >SIP, you really don't need to bother with the DESCRIBE and SETUP of >RTSP. >After the SIP negotiation, you're ready to PLAY. This leads one to >question >if all of the complexity of RTSP is required in these cases; a simpler >version of media control being desirable. > >Rob > >-----Original Message----- >From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >Of >Colin Perkins >Sent: Monday, February 06, 2006 2:57 AM >To: Teodora Guenkova-Luy >Cc: mmusic@ietf.org; Osher.Hmelnizky@audiocodes.com >Subject: Re: [MMUSIC] Re: mmusic Digest, Vol 22, Issue 3 > >SDP has the concept of "m=control ..." to signal other control >sessions. If one were to define how to signal RTSP sessions could be >setup using SIP, that would likely be the appropriate way to do it. > >This subject comes up regularly - maybe it would be appropriate for >someone to write a draft fleshing out the details? > >Colin > > > >On 6 Feb 2006, at 09:48, Teodora Guenkova-Luy wrote: > > >>SIP and RTSP are two different sessions. Their frameworks do not >>exclude the scenario that both of them shall be synchronised, >>however, there is no existing solution on such synchronisation. You >>can synchronize SIP and RTSP only at presentation level (i.e. SDP), >>like done for SIP and MRCP, as at session level SIP and RTSP are >>different instances that are not aware of each other. You could >>"misuse" the SDP SIP/MRCP attribute "a=channel:xxx" with your own >>parameters for RTSP, or use the SDP "i=" line also with your own >>paramentes, or define your own attribute line, e.g. >>"a=stacksynch:whatever". However, all these are non-standard >>solutions. >>KR, >>Teodora >> >>mmusic-request@ietf.org wrote: >> >> >> >>>Message: 1 >>>Date: Sun, 5 Feb 2006 09:41:06 +0200 >>>From: "Osher Hmelnizky" <Osher.Hmelnizky@audiocodes.com> >>>Subject: RE: [MMUSIC] Using RTSP with SIP >>>To: "Burger, Eric" <eburger@brooktrout.com> >>>Cc: mmusic@ietf.org >>>Message-ID: >>> >>><79B4F738DDD4EF4F85A4641A0FE5EFD601C89990@aclmsg.corp.audiocodes.com> >>>Content-Type: text/plain; charset="us-ascii" >>> >>>Hi, >>> >>> >>>What I'm trying to say is: why can't I use SIP for the call >>>establishment and RTSP for the stream control. How can synchronize >>>two >>>protocols on the MRF side? >>>On the client side it is no problem, but server side should be aware >>>that two sessions are interconnected to the one specific call. >>> >>>Such synchronization I saw in the SIP/MRCP draft >>>(draft-ietf-speechsc-mrcpv2-09). >>> >>> >>>Thanks a lot >>> >>> >>>Osher >>> >>> >>>________________________________ >>> >>>From: Burger, Eric [mailto:eburger@brooktrout.com] Sent: Friday, >>>February 03, 2006 4:34 AM >>>To: Osher Hmelnizky >>>Subject: RE: [MMUSIC] Using RTSP with SIP >>> >>> >>>What are you trying to accomplish? Two sessions are two >>>sessions. It >>>is either SIP or RTSP. MRCP (not an IETF standard) has two, distinct >>>sessions. >>> >>> >>>________________________________ >>> >>>From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>Behalf >>>Of Osher Hmelnizky >>>Sent: Tuesday, January 10, 2006 7:26 AM >>>To: mmusic@ietf.org >>>Subject: [MMUSIC] Using RTSP with SIP >>> >>> >>>In the last MRCP draft (draft-ietf-speechsc-mrcpv2-09), in order to >>>synchronize the SIP and MRCP Sessios, defined >>> >>>a=channel:xxx >>> >>> >>>as part of application SDP. >>> >>> >>>I'm trying to find out how I can synchronize SIP and RTSP streams >>>at the >>>Media Server layer without any indication. >>> >>> >>>As a=channel defined at the SDP level can I use this parameter to >>>sync >>>between SIP and RTSP Streams. >>> >>> >>>Thanks a lot. >>> >>> >>>Osher >>> >>> >>> >>> >>> >>>-------------- next part -------------- >>>An HTML attachment was scrubbed... >>>URL: http://www1.ietf.org/pipermail/mmusic/attachments/ >>>20060205/0ce380c0/attachment.htm >>> >>>------------------------------ >>> >>>Message: 2 >>>Date: Sun, 5 Feb 2006 08:17:22 -0500 >>>From: "Burger, Eric" <eburger@brooktrout.com> >>>Subject: RE: [MMUSIC] Using RTSP with SIP >>>To: "Osher Hmelnizky" <Osher.Hmelnizky@audiocodes.com> >>>Cc: mmusic@ietf.org >>>Message-ID: >>> >>> >>> ><330A23D8336C0346B5C1A5BB196666470228F906@ATLANTIS.Brooktrout.com> > > >>>Content-Type: text/plain; charset="iso-8859-1" >>> >>>That is something totally different and explicitly outside the >>>scope of MRCPv2. What you want is something like the mediactrl >>>work (not chartered). Search the I-D directory for mediactrl. To >>>subscribe, send 'subscribe mediactrl' to >>>majordomo@lists.ubiquitysoftware.com >>> >>>________________________________________ >>>From: Osher Hmelnizky [mailto:Osher.Hmelnizky@audiocodes.com] >>>Sent: Sunday, February 05, 2006 2:41 AM >>>To: Burger, Eric >>>Cc: mmusic@ietf.org >>>Subject: RE: [MMUSIC] Using RTSP with SIP >>> >>>Hi, >>> >>>What I'm trying to say is: why can't I use SIP for the call >>>establishment and RTSP for the stream control. How can synchronize >>>two protocols on the MRF side? On the client side it is no >>>problem, but server side should be aware that two sessions are >>>interconnected to the one specific call. >>>Such synchronization I saw in the SIP/MRCP draft (draft-ietf- >>>speechsc-mrcpv2-09). >>> >>>Thanks a lot >>> >>>Osher >>> >>>________________________________________ >>>From: Burger, Eric [mailto:eburger@brooktrout.com] Sent: Friday, >>>February 03, 2006 4:34 AM >>>To: Osher Hmelnizky >>>Subject: RE: [MMUSIC] Using RTSP with SIP >>> >>>What are you trying to accomplish? Two sessions are two >>>sessions. It is either SIP or RTSP. MRCP (not an IETF standard) >>>has two, distinct sessions. >>> >>>________________________________________ >>>From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On >>>Behalf Of Osher Hmelnizky >>>Sent: Tuesday, January 10, 2006 7:26 AM >>>To: mmusic@ietf.org >>>Subject: [MMUSIC] Using RTSP with SIP >>> >>>In the last MRCP draft (draft-ietf-speechsc-mrcpv2-09), in order >>>to synchronize the SIP and MRCP Sessios, defined >>> a=channel:xxx >>> as part of application SDP. >>> >>>I'm trying to find out how I can synchronize SIP and RTSP streams >>>at the Media Server layer without any indication. >>> >>>As a=channel defined at the SDP level can I use this parameter to >>>sync between SIP and RTSP Streams. >>> >>>Thanks a lot. >>> >>>Osher >>> >>> >>> >>> >>> >>> >>>------------------------------ >>> >>>_______________________________________________ >>>mmusic mailing list >>>mmusic@ietf.org >>>https://www1.ietf.org/mailman/listinfo/mmusic >>> >>> >>>End of mmusic Digest, Vol 22, Issue 3 >>>************************************* >>> >>> >>> >>-- >>----------------------------------------- >>Teodora Guenkova-Luy >> >>Dept. Distributed Systems, University of Ulm, Oberer Eselsberg, >>89069 Ulm, Germany >> >>Tel.: +49 (0731) 502-4148 FAX: +49 (0731) 502-4142 >> >>e-Mail: teodora.guenkova-luy@uni-ulm.de >> >>Home Page: http://www-vs.informatik.uni-ulm.de/~Guenkova/ >>----------------------------------------- >> >> >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www1.ietf.org/mailman/listinfo/mmusic >> >> > > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www1.ietf.org/mailman/listinfo/mmusic > > > -- ----------------------------------------- Teodora Guenkova-Luy Dept. Distributed Systems, University of Ulm, Oberer Eselsberg, 89069 Ulm, Germany Tel.: +49 (0731) 502-4148 FAX: +49 (0731) 502-4142 e-Mail: teodora.guenkova-luy@uni-ulm.de Home Page: http://www-vs.informatik.uni-ulm.de/~Guenkova/ ----------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www1.ietf.org/pipermail/mmusic/attachments/20060207/96ebd483/attach ment.htm ------------------------------ _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic End of mmusic Digest, Vol 22, Issue 5 ************************************* _______________________________________________ mmusic mailing list mmusic@ietf.org https://www1.ietf.org/mailman/listinfo/mmusic
- [MMUSIC] SIP/RTSP interworking steven.d.whitehead