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

From: Aaron Colwell <[email-masked]>
Date: Tue, 29 Apr 2003 10:00:54 -0700 (PDT)

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?
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?
3. Should the client and server both send RR info to eachother about the
   RTP packets they are sending?
4. Are there any requirements for the RTP packet timestamps other than
   being monotonically increasing?

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

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 29 Apr 2003 20:04:16 +0200

Hi Aaron,

See my answer below inline.

 >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.

 >   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.

 >   RTP packets they are sending?

Yes, It should report on these packets.

 >   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.

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.

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]

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 30 Apr 2003 08:54:27 +0200

Hi Aaron

I hope you don't mind that I again include the MMUSIC list. I think the 
question and replies should go there.

Aaron Colwell wrote:

>Hi Magnus,
>
>Thanks for you response. My comments are inline
>
>On Tue, 29 Apr 2003, Magnus Westerlund wrote:
>
>  
>
>>Hi Aaron,
>>
>I guess I was assuming that if the client is behind a NAT that it won't
>get any packets from the server until it sends packets to the server
>through the NAT. In this case it seems to me that the only valid thing
>for the client to do is send a compound SR and SDES packets initially.
>  
>

Yes, If the client is behind a NAT it will require that the client sends 
its RTCP packets to the server to bind them. This packet shall be a 
normal RTCP packet. So if RTCP is sent before any RTP packet has been 
sent, then the client SSRC has status as receiver only and sends RR and 
SDES. If the RTP packet(s) has been sent then it will have status of 
active sender and send SR and SDES. This doesn't matter for the binding 
mechanism. As this is based on SSRC the server shall be able to send 
replies as soon as one of the client RTCP packets reach the server.

>This comment is actually a surprise to me. I always thought that the CNAME
>was always specified by an RTP sender. I've always thought that the client
>just used the CNAME in the SDES packets sent by the server. Is that not
>the case? Perhaps this is something that needs to be clarified in the RTP
>spec. It doesn't seem to say much about who generates the CNAMEs and which
>CNAMEs are used where. It just says that all compound RTCP packets must
>have an SDES packet with CNAME field.
>

All RTP session participants MUST have its own CNAME independent if he 
is a active RTP sender or not. I think you should re-read section 6.5.1 
of draft-ietf-avt-rtp-new-12.txt. I think this is rather clear there. 
The perhaps only somewhat confusing think is the use of the word source. 
It is in some cases meaning participant due to the fact that all 
participant get a SSRC

>I like the idea of using the RTP send time here. Since we are using PT=0
>are the units still in 1/8000 of a second?
>  
>

Yes.

>I don't know if using PT=0 is a good idea or not. I'm struggling a little
>bit with what it means to get a packet without any payload data. In the
>case of PCM audio it doesn't seem to really matter, but in other payload
>formats it might. We might want to have a reserved payload type for this
>type of packet. That way we could also include some sort of challenge like
>you mention later in the document. Whatever challenge mechanism we devise,
>we should have something similar for RTCP as well. In the RTCP case we
>could probably just add a new SDES item type and do the challenge in
>there.
>  
>

Yes, this is something that needs more considerations. I think Thomas 
has some other ideas on how to accomplish this. I would also like a 
binding payload format with its own static payload type. However I don't 
know what possibilities exist to get such developed in a reasonable time 
frame.

>I agree that we should look over this section more. A few weeks ago I had
>to solve this NAT problem for streaming to a mobile phone. I didn't
>really have any specs to reference so I made up my own solution. I like
>this solution much better and I'd like to see this developed more so that
>we'll have an interoperable solution.
>  
>

Yes, there is a total lack of specified solutions for RTSP. The RTSP NAT draft is our attempt to solve this. 

Best Regards

Magnus Westerlund