Subject: RE: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions

From: Thomas Zeng <[email-masked]>
Date: Tue, 29 Apr 2003 14:24:33 -0700

>  -----Original Message-----
> From: 	Magnus Westerlund [mailto:[email-masked]]
> 
> Sent:	Tuesday, April 29, 2003 11:04 AM
> To:	Aaron Colwell; IETF MMUSIC WG
> Subject:	Re: [MMUSIC] draft-ietf-mmusic-rtsp-nat-00.txt questions
> 
> Hi Aaron,
> 
> See my answer below inline.
> 
> Aaron Colwell wrote:
> 
>  >I have a few questions about section 3.2.3 list item 8. It says
>  >"For RTCP it starts transmitting RTCP packets according to the rules."
>  >
>  >1. Does this mean that it starts sending  compound SR and SDES packets?
>  >
> 
> Depends on the RTP session state. Unless the server has not sent any RTP
> packets yet it must send RR and SDES. If it has sent RTP packets then it
> need to send SR and SDES.
> 
>  >2. Is the client supposed to created it's own CNAME for this stream of
>  >   packets or does the CNAME need to be sent from the server to the 
> client?
>  >
> The client must set a CNAME of its own. That it must always do when
> sending RTCP in a RTP session.
> 
>  >3. Should the client and server both send RR info to eachother about the
>  >   RTP packets they are sending?
>  >
> 
> Yes, It should report on these packets.
> 
>  >4. Are there any requirements for the RTP packet timestamps other than
>  >   being monotonically increasing?
>  >
> 
> No, I need to think over what would be the best strategy here. One would
> be to use the RTP send time as TS basis.
	[Thomas Zeng]  This is the reason that makes it hard to treat
ip/port binding packets as RTP packets. These binding packets are not really
media packets, yet according to RTP rules, they would have to be accounted
for in RR and SRs. All of a sudden RTSP clients would now need to send SRs
back to  RTSP servers. That probably won't please implementors of thin RTSP
clients.

> In general I think we need to further look over this section. Is it a
> good thing to use PT=0, i.e. PCM audio with no samples for these
> packets? Please comment.
	[Thomas Zeng]  How about not treating binding packets as RTP packets
at all? My suggestion would be to use a simple UDP packet that contains an
SSRC (the server SSRC as indicated in SETUP response, so as to  make it
possible to uniquely identify RTP session in the event server is sending RTP
packets from a shared UDP port in order to conserve server resources -- a
common practice among implementors of large scale servers) ? If you want to
indicate that re-transmission of binding packets are taking place, we can
put a 4- byte counter in this binding packets as well. That is, the first
binding packet is try number 1, the second is try number 2, etc...  The fact
that this binding packet is smaller than RTP / RTCP header makes it real
easy for the server to distinguish between RTP and RTCP packets and the port
binding packets. Any other packets would be disgarded. A binding packet with
incorrect SSRC or counter are also discarded.

> Best Regards
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research ERA/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 
> 
> 
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Tom Marshall <[email-masked]>
Date: Tue, 29 Apr 2003 14:41:08 -0700

> incorrect SSRC or counter are also discarded.

I have mixed feelings on this issue.  On the one hand, it isn't really an
RTP data packet.  It's just a binding packet that happens to require a
couple of the same values that are in an RTP packet.  On the other hand, the
RTP header is very well defined, it's pretty short (12 octets), and the PT
field is really the only troublesome one.  I think the other fields have
pretty obvious values.

Why can't we say that the binding packet is not an RTP packet but it is
formatted to look like one?  There may be advantages to masquerading as an
RTP packet, especially with firewalls.  We can choose some arbitrary value
for PT (I think 0 or 127 is logical) and we get the version, extension
mechanism, and sequence number for free.  What a deal.

-- 
Mountain Dew and doughnuts...  because breakfast is the most important meal
of the day.