Subject: RE: [MMUSIC] resolving open issues in offer/answer

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 21 Jan 2002 23:11:39 -0800

Sorry for the delay in reply I just got back from a month away.

With regards to the introduction of an SDP ssrc parameter (as quoted in the
email below)....

Hasn't the inclusion of a ssrc parameter been proposed and shot down
multiple times already? [For instance discussion preceding and at the London
IETF] An SDP body indicates where media should be sent (i.e. identifies a
sink); this parameter is proposing to include information about a logically
associated source in the sink description.

Don't get me wrong, I am all for being able to correlate a particular
received RTP packet stream to a received SDP offer/answer body but I merely
wished to point out that this is not the first time this has been proposed. 

Is the offer/answer model a sufficient subset of generate sdp-new model that
this is change in model is possible?

Regards,

Robert

> 
> >>1. change the ssrc when you send with the new codec set. 
> The receiver
> >>can drop uneeded codecs when it sees the new ssrc. This 
> only works for
> >>unicast.
> >>
> > 
> > Actually, I don't even think it does. If you have multiple senders
> > sending
> > media to you, how do you know which SSRC corresponds to 
> which sender ?
> > Also,
> > it is possible than an SSRC change might happen for other reasons
> > (admittedly, we are getting down to a rather small window for this
> > race).
> 
> 
> Realistically, for this to work, you would need to include the actual 
> SSRC rather than simply waiting for a change in the ssrc. That would 
> resolve the issues you raise above, but requires an additional SDP 
> parameter.
> 
> Its worth noting that there is another advantage of the ssrc 
> parameter, 
> which is that it will allow us to correlate a media stream from a 
> particular source to a specific dialog, in the event the demux is not 
> done at the port level. This will happen in the case where we have a 
> forked INVITE that results in two 200 OK. Each answerer will end up 
> sending to the same offererd port. Having something in the 
> answer, like 
> the ssrc, which will allow for disambiguation, would help.
> 
> Of course, there is the associated ugliness with collisions 
> resulting in 
> a change in ssrc....
> 
> However, this proposal is worth further consideration. It gives us an 
> explicit, reliable, rapid way to associate media streams with 
> signaling, 
> and I think thats fairly valuable. I will admit that changing 
> SSRC might 
> introduce some confusion into systems; I welcome inputs on specific 
> problems it might cause.
> 
> 
> >>2. change in set of codecs has to also be accompanied by a port
> >> change; when you see data on the new port, you can unload 
> any unneeded codecs.
> >>
> > 
> > However, such a requirement interacts with resource reservation in a
> > negative way so I'd rather not do that. Out-of-order 
> delivery could also
> > lead to unnecesarry discard of some packets (small window again
> > admittedly).
> 
> 
> Good point on the resource reservation. It would also force SRTP 
> rekeying for the same reasons. There is also the general "don't use 
> addresses/ports for application layer indications" as these 
> eventually 
> get you in trouble with nat. No need to add more such things 
> at this time.
> 
> 
> > 
> > Fundamentally, I don't believe the synchronization problem 
> can be solved
> > completely and hence we end with a heuristic no matter what. In tha
> > case,
> > I'd prefer something very simply that doesn't rely on 
> SSRC's, sequence
> > numbers or is tied to the specifics of the media stream in any other
> > way. I
> > will contend, that if the answerer sends a media packet and 
> an answer at
> > time t, then in practice it is *very* likely that the media 
> packet will
> > arrive no later than the answer at the offerer. In 
> practice, this means
> > that
> > the offerer MAY simply stop accepting according to the old 
> offer at the
> > time
> > it receives the answer.
> 
> 
> This is more or less exactly what I proposed initially in the 
> meeting; I 
> just added 1m for safety.
> 
> 
> > 
> > Also note that this issue applies equally well to the 
> answerer, i.e. at
> > what
> > point does the answerer stop accepting media according to the old
> > offer/answer exchange (I don't believe there was any text 
> proposed for
> > this). This problem is actually worse inasmuch as the 
> answerer doesn't
> > know
> > when/if the offerer actually got the answer (not that I'm 
> proposing it,
> > but
> > it's hard to see how you can solve this without a 3-way handshake).
> 
> 
> The SSRC proposal above would solve that.
> 
> 
> > 
> > One idea would be to put constraints on allowable operation 
> while there
> > is
> > an outstanding offer in place. More specifically, if the 
> current media
> > stream has codecs X and Y as allowable codecs and the new offer has
> > codec X
> > and Z as allowable codecs, then you should not send media 
> with codec Y
> > while
> > the offer is outstanding. That way, the answerer can stop 
> listening for
> > codec Y at the time the answer is sent. However, in practice this is
> > probably not all that desirable, e.g. consider the case 
> where X is RFC
> > 2833,
> > and Y and Z are voice codecs, or the case where X is a high-bw codec
> > needed
> > for voiceband date transfer and Y and Z are codecs used for normal
> > voice.
> 
> 
> It also wouldn't work in the case where the new offer has no 
> codecs in 
> common with the old. Furthermore, if the intersecting codec 
> was not the 
> highest preference one, you would end up using this 
> intermediate codec 
> for just one RTT, that probably won't sound all that great.
> 
> 
> -Jonathan R.
> 
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
> Chief Scientist                         First Floor
> dynamicsoft                             East Hanover, NJ 07936
> [email-masked]                 FAX: (973) 952-5050
> http://www.jdrosen.net                  PH:  (973) 952-5000
> http://www.dynamicsoft.com
> 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 23 Jan 2002 16:52:31 -0500

> associated source in the sink description.

I think the usage in that other debate was different; there, it was one 
side INSTRUCTING the other side what SSRC to use, here, it is one side 
INFORMING the other side what SSRC it will use.

In any event, I haven't proposed this. The conclusion of this thread was 
to document the three mechanisms we have discussed (change PT, change 
port, timer), as all three are local implementation decisions, and none 
of them may be needed in many cases anyhow. Text on that will appear in 
offer-answer -01 (actually, draft-ietf-mmusic-sdp-offer-answer-00) which 
will appear shortly after bis-06, next week hopefully.

-Jonathan R.