Subject: [MMUSIC] RTSP mobility

From: "Enrico Balatti" <[email-masked]>
Date: Mon, 15 Dec 2003 12:17:55 +0100

Dear all,

in the European IST Project EVOLUTE (http://evolute.intranet.gr ) my
organization have developed a solution for RTSP mobility. In our
implementation we used as RTSP server (Darwin Streaming Server) and as
RTSP client (MPEG4IP player). At the beginning we followed the paper :
"Application Layer Mobility using SIP" written by H. Schulzrinne, E.
Wedlund. The paper suggests the client issues a SETUP message after
detecting that an handoff happens. In this SETUP message the client
indicates its new IP address to which the RTP traffic must be delivered.

This solution worked fine, but during the handoff the player window had
become blue for few seconds and the clients had some problems in  the
re-synchronization with the incoming RTP streams. In order to overcome
this bad behaviour we chose a different approach: when the handoff takes
place, the client sends a PAUSE message, then it sends the new SETUP and
final it restarts the streams with a PLAY message. In this way the
player window freezes on the last received frame and after the handoff
restarts from the subsequent frame.

We know that this implementation has some faults:

1) We use the "destination" field of the transport header for indicating
the new IP address used by the client, instead of the field "dest_addr"
as the last RTSP draft and Magnus suggested. We are fully agree that no
new headers or fields are needed in the RTSP protocol for this issue,
because "dest_addr" fulfils all requirements. However we couldn't use it
because the MPEG4IP version we have used doesn't support this field.

2) during the handoff we send 5 requests message for an Audio-video
stream (1 PAUSE, 2 SETUP and 2 PLAY) and the server must send 5
response. This behaviour increases the handoff delay, however pausing
the stream and freezing the player window on the last received frame has
a good impact on the user perception of the service.

Taking into account this experience we would like to propose a new
approach for managing the RTSP mobility:

1) If  the Service Provider would like to offer a RTSP service in a
mobile environment where handoffs can happen, both client and server
must support the "dest_addr" and "source_addr" field in the transport
header. 

2) the server detects the handoff if it receives a SETUP message for a
running RTSP session and if this SETUP message contains in the
"dest_addr" field an IP address different from the IP address the server
is using in that RTSP session for sending RTP traffic.

3) In order to achieve a correct synchronization of the RTP streams
after the handoff, the SETUP message should contains an indication of
the last frame of the stream received before the handoff. To achieve
this goal, we propose to extend the usage of the RTP-info also to the
SETUP request and to set the indication of the last frame in the
"range" or the "seq" field.

4) In order to reduce the number of requests sent during the handoff and
not to make worse the user perception of the handoff, we propose the
following state machine behaviour for both clients and servers: 
           a) when the clients detects the handoff, it pause all streams
internally (without sending
              any PAUSE message), sends the SETUP message for each
active stream and 
               after receiving the 200 OK from server, it plays again
all the streams (without
               sending any PLAY message)

           b) when the server receives a SETUP message for a active RTSP
session, it verify if this  
              SETUP is related to an handoff. If yes it pauses the RTP
streams of the RTSP session    
              indicated in the message; it applies the changes in the
RTP IP addresses and ports, 
              then it sends a 200 OK response (supposing that there
aren't errors in the SETUP 
              message and in the following elaborations) and it restarts
sending the RTP traffic.

Any comments and suggestions are welcomed.

We will collect all the comments that will come out from the discussion
and we will provide an draft on the RTSP mobility.

Best Regards

Enrico

--------------------------------------------
Ing Enrico M. Balatti
CEFRIEL - Politecnico di Milano
ICT Center of Excellence For Research,
Innovation,Education & industrial Labs
partnership
via Fucini 2, 20133 Milano (ITALY)
voice: +39 0223954327 fax: +39 0223954527
e-mail: [email-masked] www.cefriel.it
--------------------------------------------

---

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 15 Dec 2003 11:18:46 -0500

Enrico,
       
       I guess  what we are looking  for is a  solution for supporting
       fast-handoff for redirecting the  media after the IP address is
       obtained on the mobile which  of course has its own delay based
       on the  type of  address acquisition (DHCP/PPP).   Limiting the
       number of  signaling messages will definitely  help the handoff
       related loss,  or redirecting the  transient media will  help a
       bit also if one plans to use the existing methodology as it
       is. Redirecting the transient data can be done in several ways.

Thanks
Ashutosh

> ------_=_NextPart_001_01C3C2FD.169461B5
> Content-Type: text/html;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 6.0.6249.1">
> <TITLE>RTSP mobility</TITLE>
> </HEAD>
> <BODY>
> <!-- Converted from text/rtf format -->
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">Dear all,</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">in the European IST Project EVOLUTE (</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><A HREF=3D"http://evolute.intranet.gr"><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"><U></U></SPAN><U><SPAN =
> LANG=3D"en-gb"><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Courier =
> New">http://evolute.intranet.gr</FONT></SPAN></U><SPAN =
> LANG=3D"it"></SPAN></A><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New"> ) my organization have developed a solution for RTSP mobility. In =
> our implementation we used as RTSP server</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
> SIZE=3D2 FACE=3D"Courier New">(D</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New">arwin Streaming Server</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New">)</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New"> and as RTSP client</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
> SIZE=3D2 FACE=3D"Courier New">(</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New">MPEG4IP</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
> SIZE=3D2 FACE=3D"Courier New">player</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New">)</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New">. At the beginning we followed the paper : =
> &#8220;Application Layer Mobility using SIP&#8221; written by H. =
> Schulzrinne, E. Wedlund. The paper suggests the client issues a SETUP =
> message after detecting that an handoff happens. In this SETUP message =
> the client indicates</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New"> it</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">s new IP address to which the RTP traffic must be delivered. =
> </FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">This solution worked fine, but during the handoff the player window =
> had become blue for few seconds and the clients had some problems =
> in&nbsp; the re-synchronization with the incoming RTP streams. In order =
> to overcome this bad behaviour we chose a different approach: when the =
> handoff takes place, the client sends a PAUSE message, then it sends the =
> new SETUP and final it restarts the streams with a PLAY message. In this =
> way the player window freezes on the last received frame and after the =
> handoff restarts from the subsequent frame.</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">We know that this implementation has some faults:</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">1) We use the &quot;destination&quot; field of =
> the</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
> New">transport</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New"> header for indicating the new IP address used by the client, =
> instead of the field &quot;dest_addr&quot; as the last RTSP draft and =
> Magnus suggested. We are fully agree that no new headers or fields are =
> needed in the RTSP protocol for this issue, because =
> &quot;dest_addr&quot; fulfils all requirements. However we couldn't use =
> it because the MPEG4IP version we have used doesn't support this =
> field.</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">2) during the handoff we send 5 requests message for an Audio-video =
> stream (1 PAUSE, 2 SETUP and 2 PLAY) and the server must send 5 =
> response. This behaviour increases the handoff delay, however pausing =
> the stream and freezing the player window on the last received frame has =
> a good impact on the user perception of the service.</FONT></SPAN></P>
> <BR>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">Taking into account this experience we would like to propose a new =
> approach for managing the RTSP mobility:</FONT></SPAN></P>
> 
> <P ALIGN=3DJUSTIFY><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">1) If&nbsp; the Service Provider would like to offer a RTSP service =
> in a mobile environment where handoffs can happen, both client and =
> server must support the &quot;dest_addr&quot; and =
> &quot;source_addr&quot; field in the</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
> SIZE=3D2 FACE=3D"Courier New">transport header</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New">. </FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">2) the server detects the handoff if it receives a SETUP message =
> for a running RTSP session</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New"> and if</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
> New">this SETUP message contain</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New">s</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New"> in the&nbsp; &quot;dest_addr&quot; =
> field</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New"> an IP address</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New"> different from the IP address the server is using in that RTSP =
> session for sending RTP traffic.</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">3) In order to achieve a correct synchronization of the RTP streams =
> after the handoff, the SETUP message should contain</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New">s an indication of the last frame of the =
> stre</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">am received before the handoff.</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT =
> SIZE=3D2 FACE=3D"Courier New">To achieve this goal, we propose =
> t</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New">o extend the usage of =
> the RTP-info also to</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
> New">the SETUP</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
> New">request and to set the indication of the last frame in =
> th</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New">e</FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT =
> SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"en-gb">&nbsp;<FONT SIZE=3D2 FACE=3D"Courier New"> =
> &quot;range&quot; or</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
> New">the</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New"> &quot;seq&quot; field</FONT></SPAN><SPAN LANG=3D"it"></SPAN><SPAN =
> LANG=3D"it"></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">.</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">4) In order to reduce the number of requests sent during the =
> handoff and not to make worse the user perception of the handoff, we =
> propose the following state machine behaviour for both clients and =
> servers: </FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a) =
> when the clients detects the handoff, it pause all streams internally =
> (without sending</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
> bsp;&nbsp; any PAUSE message), sends the SETUP message for each active =
> stream and </FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
> bsp;&nbsp;&nbsp; after receiving the 200 OK from server, it plays again =
> all the streams (without</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
> bsp;&nbsp;&nbsp; sending any PLAY message)</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b) =
> when the server receives a SETUP message for a active RTSP session, it =
> verify if this&nbsp; </FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
> bsp;&nbsp; SETUP is related to an handoff. If yes it pauses the RTP =
> streams of the RTSP session&nbsp;&nbsp;&nbsp; </FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
> bsp;&nbsp; indicated in the message; it applies the changes in the RTP =
> IP addresses and ports, </FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
> bsp;&nbsp; then it sends a 200 OK response (supposing that there aren't =
> errors in the SETUP </FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
> bsp;&nbsp; message and in the following elaborations) and it restarts =
> sending the RTP traffic.</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">&nbsp;</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">Any comments and suggestions are welcomed.</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
> New">We will collect all the comments that will come out from the =
> discussion and we will provide an draft on the RTSP =
> mobility.</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">Best Regards</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">Enrico</FONT></SPAN></P>
> <BR>
> <BR>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"></SPAN><A NAME=3D""><SPAN =
> LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">--------------------------------------------</FONT></SPAN></A></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">Ing Enrico M. Balatti</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">CEFRIEL - Politecnico di Milano</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">ICT Center of Excellence For Research,</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">Innovation,Education &amp; industrial Labs</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">partnership</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">via Fucini 2, 20133 Milano (ITALY)</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">voice: +39 0223954327 fax: +39 0223954527</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">e-mail: [email-masked] www.cefriel.it</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it-it"><FONT SIZE=3D2 FACE=3D"Courier =
> New">--------------------------------------------</FONT></SPAN></P>
> 
> <P ALIGN=3DLEFT><SPAN LANG=3D"it"></SPAN></P>
> 
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C3C2FD.169461B5--
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic

Ashutosh 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic