*Please note the hexadecimal=
 octet 0x36 should not be included in any=20
part of a RTSP message, if present it should be replaced with binary=20
escaped sequence as defined in: <consensus>*.
*Please note =
the hexadecimal octet 0x24 should not be included in any=20
part of a RTSP message, if present it should be replaced with binary=20
escaped sequence as defined in: <consensus>*.

   S->C: GET_=
PARAMETER rtsp://example.com/fizz=
le/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15

           packets_received
           jitter
S->C: $\000{2 b=
yte length}{"length" bytes data, w/RTP header
 S->C: $\000{2 byte length}{&=
quot;length" bytes data, w/RTP header}C->S: RTSP/1.0 200 OK
           CSeq: 431
           Content-Length: 46
           Content-Type: text/parameters

           packets_received: 10
           jitter: 0.3838

     S->C: $\000{2 byte length}{"length" bytes da=
ta, w/RTP header}
     S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

*Please note the hexadecimal octet 0x36 s=
hould not be included in any=20
part of a RTSP message, if present it should be replaced with binary=20
escaped sequence as defined in: <consensus>*.
*Please note the hexadec=
imal octet 0x24 should not be included in any=20
part of a RTSP message, if present it should be replaced with binary=20
escaped sequence as defined in: <consensus>*.

This can be visualized under the following circumstance:

   S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15

           packets_received
           jitter
S->C: $\000{2 b=
yte length}{"length" bytes data, w/RTP header
 S->C: $\000{2 byte length}{&=
quot;length" bytes data, w/RTP header}C->S: RTSP/1.0 200 OK
           CSeq: 431
           Content-Length: 46
           Content-Type: text/parameters

           packets_received: 10
           jitter: 0.3838

 =

     S-&g=
t;C: $\000{2 byte length}{"length" bytes data, w/RTP header}
     S->C: $\001{2 byte length}{"length" bytes  RTCP packet}

This is a =
call to adopt draft-singh-avtcore-mprtp-10 =
to address the new milestone
 source:
          If the source address for the stream is different than can be
          derived from the RTSP endpoint address (the server in playback
          or the client in recording), the source MAY be specified.

 Transport           =3D    "Transport" ":"
                            1\#transport-spec
   transport-spec      =3D    transport-protocol/profile[/lower-transport]
                            *parameter
   transport-protocol  =3D    "RTP"
   profile             =3D    "AVP"
   lower-transport     =3D    "TCP" | "UDP"
   parameter           =3D    ( "unicast" | "multicast"=
 )
                       |    ";" "destination" [ "=
=3D" address ]
                       |    ";" "interleaved" "=3D=
" channel [ "-" channel ]
                       |    ";" "append"
                       |    ";" "ttl" "=3D" t=
tl
                       |    ";" "layers" "=3D"=
; 1*DIGIT
                       |    ";" "port" "=3D" =
port [ "-" port ]
                       |    ";" "client_port" "=3D=
" port [ "-" port ]
                       |    ";" "server_port" "=3D=
" port [ "-" port ]
                       |    ";" "ssrc" "=3D" =
ssrc
                       |    ";" "mode" =3D <"&g=
t; 1\#mode <">
   ttl                 =3D    1*3(DIGIT)
   port                =3D    1*5(DIGIT)
   ssrc                =3D    8*8(HEX)
   channel             =3D    1*3(DIGIT)
   address             =3D    host
   mode                =3D    <"> *Method <"> | Metho=
d

Since 'source' is not =
listed I don't know the syntax, I assumed it to be an "IPAddress&q=
uot; however the text sates "address" so I imagine if I found a &=
#39;source=3D1.2.3.4:1554' that wou=
ld be valid however I want to make sure since there isn't any syntax sp=
ecified in the RFC.=C2=A0
A=
lso I would wonder is there any restriction on specifying a port or address=
 range also ? e.g. 'source=3D1.2.3.=
4/321202/2'
=
I belie=
ve there was a similar issue with Rtp-Info headers which was fixed in '=
biz' however this among other issues were not addressed and I am wonder=
ing if any other updates will be made to this RFC before 2.0 Draft is final=
ized.
Hopefully this won=
9;t have to be added to my list of `issues` but unless I am missing somethi=
ng I will also have to file=C2=A0errata=C2=A0for this.