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

From: Flemming Andreasen <[email-masked]>
Date: Fri, 04 Jan 2002 12:58:52 -0500

Jonathan Rosenberg wrote:

> Flemming Andreasen wrote:
>
> >
> > Jonathan Rosenberg wrote:
>
>
> >>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.

That's a good point - it would be very helpful indeed.

>
>
> Of course, there is the associated ugliness with collisions resulting in
> a change in ssrc....
>

I think it is imperative, that such an "SSRC" attribute only be advisory in nature,
i.e a hint. If you receive packets with a known SSRC, you know what to do, but if you
receive packets with an unknown SSRC, everything must still work. Also, since not all
implementations would support such an extension, we still need rules for what to do
in the absence of this attribute and/or other SSRCs.

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

> I will admit that changing SSRC might
> introduce some confusion into systems; I welcome inputs on specific
> problems it might cause.
>

Again, I think it is important to have some flexibility surrounding the use of such
an SSRC attribute, and see it as an optimization hint as opposed to enforcing strict
rules.

As far as problems go, SRTP security contexts (which key off the SSRC) would seem to
be potentially troublesome.

-- Flemming

--
Flemming Andreasen
Cisco Systems

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Jan 2002 21:50:38 -0500

Flemming Andreasen wrote:

> be potentially troublesome.

That is true. Paul K. also pointed out that it is RTP specific.

Let me summarize where we are. The problem was how to know that it is 
safe to "unload" a codec after a change. This needs to be syncrhonized 
with some event in the media stream. The proposals we've entertained:

1. use different ssrc once new codecs are in use

CONS
   requres SRTP re-keying on change in codecs.
   SSRCs can also change due to collisions
   Requires a new SDP attribute
   RTP specific
   sender oriented (that is, if B needs an indication of the change, its 
up to A to support it, since the sender chooses the SSRC)

PROS

   also helps disambiguage multiple media streams to the same port in 
case the offer is in a forked invite

2. use different port once new codecs are in use

  CONS

    may require new resource reservations
    requires SRTP rekeying
    using transport IDs as application IDs is a general bad idea because 
of nat (although I can't think of a specific issue here)

  PROS

    not RTP specific
    doesn't require any new SDP attributes

3. use different payload type number

  CONS

    doesn't work with static payload types
    implementations don't support changing pti for the same codec
    may exhaust limited dynamic PT space

  PROS

    no impact on resource reservation
    no new SDP attributes
    no impact on SRTP rekeying

4. use a timer; just unload the old codec after 1 minute

   CONS

     not exact
     kludgey

   PROS

     requires no new SDP attributes
     no impact on resource reservation
     not rtp specific
     no impact on SRTP rekeying

I think its probably provable that no solution can achieve all of the 
desired goals here. Using a specific indicator in the media stream means 
it has to be something in the RTP packet. Of the headers in the RTP 
packet, most cannot be used at all (version, padding, extension bit, 
csrc count, marker, sequence number, timestamp), two are discussed above 
(ssrc, pti), and another possibility is to define an extension that 
would include an identifier. I think an RTP extension just for this 
purpose is overkill. Then, there are things in the UDP header - the 
destination port is discussed above. Source port cannot be used because 
of nat. Then, there is IP header. We could use different destination IP 
addresses, but there are the same issues as separate ports above, and it 
would require multi-homed hosts. Different source addresses doesn't work 
with nat. So, we have provably exhausted the set of in-packet 
indicators. Then, there is a non-packet indicator, which is the timer 
above. THus, we've got everything listed, and nothing seems ideal.

I think the best solution is to punt it ;). Seriously, though, this may 
be a non-issue in many implementations, where there is no notion of 
unloading a codec. If an implementation needs to know when its safe to 
stop being prepared to receive with a codec, it can employ either the 
timer approach or the port change mechanism, both are local 
implementation choices that require no additional protocol semantics. 
So, we can describe both, discuss the issues, and leave it at that.

Comments?

-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

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 08 Jan 2002 10:35:55 -0500

Jonathan Rosenberg wrote:

> purpose is overkill.

Maybe, however as you noted earlier, we also have the related problem of
correlating multiple media streams with multiple answers, e.g. in the case of
SIP forking.

> Then, there are things in the UDP header - the

Might as well describe the payload type change approach as well then since it
seems to have the fewest problems as long as it's optional.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 08 Jan 2002 23:59:33 -0500

Flemming Andreasen wrote:

>>I think the best solution is to punt it ;). Seriously, though, this
>>
> may 

Fair enough. I will be sure to document the limitations as well.

Any other comments? This is the main open issue left in O/A; once there 
is agreement I can update and resubmit and we can then move into WGLC on it.

-Jonathan R.