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

[Gonzalo Camarillo <[e-mail]>]

Hello Christer,

Christer Holmberg wrote:
> 
> Hi,
> 
> Gonzalo Camarillo wrote:
> >
> > 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.
> 
> I guess that sounds ok. However, considering the manyfolks mechanism
> (using 18x and PRACK for the negotiation), in that case we would going
> towards two different methods of doing 3-way handshake...

No, we are not. 18x and PRACK is still an offer/answer model.

> I think the problem is, that so far we have been talking pretty much
> about codecs ("I tell you what codecs I support in the INVITE, and you
> tell me what codecs you support in the 200..." - period. ), and not
> multiple streams.
> 
> So, one question is: if A initiates the session, giving one or more
> streams, should B be allowed to add more streams in the session
> establishment? One could say no, and that B must send a re-INVITE after
> the 200/ACK if it wants to add more streams.

This is exactly what I have explained in my previous mail. Since we use
an offer/answer model, the callee needs to re-INVITE in order to add
more streams. This was discussed a lot of IETFs ago in the MMUSIC
session.


> I agree that this was the initial problem, but I think they are related
> to each other. If we DO have a mechanism to identify the streams per
> session, it is then easier to come up with mechanisms/rules how to
> re-use them - AND how to add/remove streams during the call WITHOUT
> having to re-send the whole SDP in the re-INVITE.


Sending the whole SDP in the INVITE is NOT a disadvantage. It is a
desing rule that SIP developers MUST follow. It avoids synchronization
problems and allows easier failure recovery.

And as I said before, it is not necessary to have identifiers in order
to reuse stream positions.

Regards,

Gonzalo


> 
> We should also remember that "setting the port to zero" is very IP
> specific (similar to the media on-hold issue), so  it won't work very
> good with ATM.
> 
> Regards,
> 
> Christer Holmberg
> Ericsson Finland
> 
> 
> > 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]

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