Re: [Sip] Open Issue #146: Re-use disabled streams

[Gonzalo Camarillo <[e-mail]>]

Hello,

> I THINK that the FID currently doesn't support the identifying of
> streams for the whole sessions. However, I see no reason why it
> shouldn't be possible to update the draft (I guess Gonzalo is the man to
> make that decission)

My first idea related to FID was to use it exactly for this purpose:
"SDP media alignment". However, the optimization I was thinking of at
that point of time was a different one. If a UAC sends an INVITE with
two m lines and the UAS wants to establish a session with 3 m lines the
server needs to accept the session and later re-INVITE. With an m line
identifier it is possible to add new streams in the 200 OK and then get
the final SDP in the ACK.

This would have been a big gain (3 messages instead of 6), but it
requires a 3-way handshake. SIP just provides a 2-way handshake
(regarding SDP exchange). Using a 3-way handshake would make 3pcc
impossible. That's why we abandoned that original idea.


Now, coming back to our current problem, using identifiers just to reuse
m lines is overkill. We just need to allow that the position of an m
lines that has been answered with port zero can be reused. Adding stream
identifiers does not give us any extra gain.

Therefore, let us focus in our real problem. The decision we have to
make is: can a UA reuse a position in the SDP when that media stream has
been rejected?

My personal opinion is: if any implementor has a problem with this,
let's keep the mechanism as it is right now (that is, we dissallow
position reuse). If implementors feel that this change will not break
significally their code, let's go for it.

Regards,

Gonzalo



, or otherwise write a new draft. We may even want
> to define more new stream related attributes, so maybe the name should
> be "SIP multimedia support", or something...
> 
> Of course, IF we would put the whole media handling in a specific draft,
> the question is if this would be included there too.
> 
> I don't see too big backward compability issues with this - since it
> currently simply doesn't work. And, if needed it is always possible to
> define an option-tag for the feature, so...
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> Jonathan Rosenberg wrote:
> >
> > This thread has stalled. Since this is a bis open issue, I would like people
> > to please make a priority of getting this resolved.
> >
> > Some comments below.
> >
> >
> >
> > > -----Original Message-----
> > > From: Christer Holmberg [mailto:[e-mail]]
> > > Sent: Wednesday, August 29, 2001 2:59 AM
> > > To: Kim Liu
> > > Cc: Jonathan Rosenberg; '[e-mail]'
> > > Subject: Re: [Sip] Open Issue #146: Re-use disabled streams
> > >
> > >
> > >
> > > Hi,
> > >
> > > How about using the FID (or something similar) as a stream identifier,
> > > identifying a stream for the whole session (not only within a specific
> > > SDP)? Then it would be very easy to
> > > add/remove/change/whatever streams.
> > >
> > > For example, assume a case where I set up a session with 5 streams.
> > > Then, later in the session, I want to add one stream and remove one of
> > > the old ones. By using identifiers one does not have to include any
> > > information about the streams that are not affected by the mid-session
> > > change.
> >
> > Using an explicit stream ID would definitely make this issue go away. It
> > would also solve this particular issue for bis - the base spec disallows
> > reuse. If you want to reuse, you need to implement the FID extension that
> > supports this. Allowing reuse is not backwards compatible anyway.
> >
> > However, its not clear to me that FID, as currently specified, has this
> > semantic. Here, we are talking about using the stream ID to correlate
> > streams ACROSS re-invites. I don't think it means that. Its currently meant
> > to associate streams together within a single INVITE/2xx. I'd appreciate
> > input from Gonzalo and the mmusic folks about whether or not this usage
> > fits, and/or should be added, to the fid draft.
> >
> > > Kim Liu wrote:
> > > >
> > > >
> > > > My inclination is to allow reuse, but I don't think it can
> > > > be done.  Particularly given the restriction on dynamic PT
> > > > reuse in issue #23.
> >
> > These are unrelated. I don't see an issue.
> >
> > > > Since the INVITE with SDP is used for
> > > > recovery, reusing/rewriting an old media stream slot in the
> > > > SDP might erase/hide information about the previous state
> > > > of the call (which dynamic PTs have been used, plus any
> > > > endpoint, media, or application specific information
> > > > associated with the closed media stream) though I am unaware
> > > > of any application which is doing this today.
> >
> > Forgetting about reusing stream slots, if you do a re-invite with a new set
> > of codecs, there is no need to retain the list of old codecs, and their pt.
> > THus, this information is normally lost anyway. I'm not sure it matters.
> >
> > > >  Unfortunately,
> > > > since the INVITE/200 + SDP is used for call recovery,
> > > > that reuse will have to be avoided in order to maintain
> > > > a full history/state of the call in case recovery is
> > > > necessary.
> >
> > I do not see why that is needed. The only thing you need to recover is the
> > current state, not the history. You don't have the history normally anyway.
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [e-mail]                     FAX:   [phone]
> > http://www.jdrosen.net                      PHONE: [phone]
> > http://www.dynamicsoft.com

-- 
Gonzalo Camarillo                    Phone :   [phone]
Columbia University                  Mobile:  [phone]
472 Computer Science Building        Fax   :  [phone]
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [e-mail]

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip