Subject: RE: [MMUSIC] NOT encapsulating for media-loopback

From: "Venna, Nagarjuna" <[email-masked]>
Date: Fri, 4 Aug 2006 11:14:28 -0400

-----------------------------------------------------------------------------------------------------------------------------------------------
Service Quality Matters. Test the performance and quality of your VoIP or IP video service at: 
http://www.TestYourVoIP.com
http://www.TestYourIPVideo.com-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Friday, August 04, 2006 6:31 AM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [MMUSIC] NOT encapsulating for media-loopback
>> It doesn't work though: the returned stream doesn't conform to the 
>> RTP specification, since there's a persistent SSRC collision, until 
>> the SSRC, sequence number and timestamp are rewritten, and 
>> appropriate RTCP generated. Once that's been done, you can't tell if 
>> there is congestion on the forward path, unless you encapsulate, 
>> which brings us back to something like the solution in media- 
>> loopback-04.
>>
>> The mirror does re-write the sequence and timestamp of the RTP it 
>> sends - with its own values.  That won't affect the source's seq and 
>> timestamp, because their copies are safely inside the payload.  If 
>> using the same SSRC is a big deal even for loopback, you can define 
>> the mirror change that too in the draft, and have the source embed 
>> that in its payload as well if it's of interest to it.

>I don't understand why you think a copy of just the payload is easier
than copying from the header into the payload?

It's probably because in the case of payload only copying, you can
operate on the received buffer (no copy) instead of having to create a
new buffer and do the copy. However, it only works if there are no CSRC
identifiers in the original packet.

Thanks,
nagarjuna

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

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 4 Aug 2006 20:20:45 -0400

> -----Original Message-----
> From: Venna, Nagarjuna [mailto:[email-masked]]
> 
> new buffer and do the copy. 

Yup.  For hardware/firmware that could be a big deal.  Even for a poor-man's
C-based software implementation it can just cast a struct of the header,
overwrite some word members, and ship it back out - with no memory move or
copy. (not that I advocate such an approach mind you)  If you make the
mirror only copy the header into the payload instead of encap it all, then
it's not as big a deal, but then you lose part of the payload.  

With copying the payload (or just leaving it alone), you let the source
decide what it wants in the payload, where to put it, etc.  For example,
maybe the source would like to store wallclock/UTC time in the payload, so
when it gets it back it knows when it sent it using UTC instead of the
sample-rate timestamp clock.  I don't know; I don't make a source.  :)

> However, it only works if there are no CSRC

CSRC is inserted by a mixer, so I don't see how that's really applicable.
(but a mirror implementation can always do something different if it sees
the CC field > 0, I presume)  

-hadriel

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 4 Aug 2006 14:26:58 -0700

> From: Venna, Nagarjuna [mailto:[email-masked]]
> Sent: Friday, August 04, 2006 8:14 AM
> To: Colin Perkins; Hadriel Kaplan
> Cc: [email-masked]
> Subject: RE: [MMUSIC] NOT encapsulating for media-loopback

> identifiers in the original packet.

When the end points are operating under offer/answer model the topology
becomes point to point. In this scenario, if I am correct, there should
be zero CSRCs in the RTP header. 

- - - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Aug 2006 10:17:57 +0100

On 4 Aug 2006, at 22:26, Desineni, Harikishan wrote:
...
> be zero CSRCs in the RTP header.

That's not guaranteed. For example, you might be talking to a mixing  
MCU.

Colin