Subject: [MMUSIC] Comments on draft-ietf-mmusic-ice-07

From: Magnus Westerlund <[email-masked]>
Date: Mon, 20 Mar 2006 05:30:19 +0100

Hi,

I have made a quick review of the changes in this version. A few thing I
reacted on:

Section 7.13:

"To signal to the jitter buffers that this change has happened, it is	
RECOMMENDED that, when an agent switches transmission of media from	one 
candidate pair to another, it sets the RTP marker bit."

I understand the intention here. However as the marker bit is media
format specific I don't the recommendation can be written as specified.
This recommendation would primarily be applicable to audio codecs. But
not even all audio codec has this definition that makes the
recommendation suitable. I rather think that this should be triggered by
the change of the source address. In those cases the offer or answer 
reaches the peer before the media there should be a warning to the 
buffering about the change.

The second issue with this mechanism is to indicate that the potential
change in source address shall not be used as an indication of SSRC
collision.

Sorry to not provide a text proposal at this time.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Mar 2006 09:25:44 -0500

Thanks for the comments, as always. More inline.

Magnus Westerlund wrote:

> RECOMMENDED that, when an agent switches transmission of media from    
> one candidate pair to another, it sets the RTP marker bit."
> 
> recommendation suitable. 

Hmm; I thought this definition was at least common across audio codecs. 
I can update the text to say that this is specific for audio.

> I rather think that this should be triggered by
> the change of the source address.

We discussed this during the informal get together at the last IETF. I 
vaguely recall that we concluded that this didn't work, but at the 
moment, I can't recall why.

Certainly one potential issue is that the thing which might be changing 
is the destination address, not just the source. But if you extend it to 
both, that would cover that case.

> In those cases the offer or answer 

True; though with the -07 spec there can be usage of a new candidate 
without signaling in offer/answer.

> change in source address shall not be used as an indication of SSRC

Right - I hadn't considered SSRC collision at all. I think that the 
right solution here is that the UA will actually clearly know which 
correspondent media is coming from; the STUN connectivity checks will 
map the 5-tuple of the RTP packets to a specific offer/answer exchange. 
Thus, multiple senders that are a consequence of forking, would be known.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com