Subject: [Sip] grouping bis open issues: SDP related

From: Rohan Mahy <[email-masked]>
Date: Sat, 08 Sep 2001 10:53:52 -0700

Hi,

Based on Jonathan's open issues presentation ( 
http://www.softarmor.com/sipwg/meets/ietf51/slides/pres-jdrosen-sip_bis_open 
-ietf51.ppt ), and the closure of 6 of those issues on the list last night, 
I count 19 open issues remaining, of which 7 are CANCEL related, and 7 are 
SDP related.  Perhaps if we discuss these in a group, we might close them 
faster.

The following 7 open issues are all related to SDP processing:
I've also added my own comments/proposals/2 cents inline:

 >#21  "SDP uni/multi processing rules too granular"
 >SDP section defines processing separately for multicast and unicast
 >BUT, does so at the level of entire SDP.  An SDP can have a mix of both.
 >Proposal: Restructure appendix to treat uni/multi on a stream by stream basis
 >
 >#26 "misaligned SDP"
 >Bis-02 used to say that a UA SHOULD be prepared to handle misaligned SDP
 >Gave some vague guidelines what to do, not clear what it means
 >Bis-03 has removed this.  General rule: error handling is your own concern
 >No comments received on this removal, this feature had been discussed on
 >list.  Is this OK?
 >Proposal: yes
 >
 >#133 "on-hold indication"
 >Using 0.0.0.0 on-hold has some issues:
 >No IP for receiving receiver reports, IPv4 specific, Makes no sense for
 >connection oriented media, IP change may require change in security context.
 >Be explicit, not implicit
 >Proposal:
 >Use a=sendonly for bidirectional media,
 >Use a=inactive for recvonly,
 >Must still be prepared to receive 0.0.0.0 for backwards compatibility, but
 >don't send anymore,
 >No other explicit hold indicator needed
 >
 >#150 "saying don't send"  (related to #133)
 >Spec has many ways to say "don't send me media":
 >A=sendonly, A=inactive, Bw=0, Port zero, 0.0.0.0
 >Do we need all of these??
 >Answer: no, but we need several:
 >A=sendonly stops receipt of media
 >A=inactive stops RTP/RTCP in both directions
 >Port zero terminates media stream (stop tools)
 >All others not needed
 >OK?
 >
 >#163 "where does SDP section live"
 >Issues: SIP spec has an appendix with SDP usage;
 >Not really a SIP issue at all;
 >Other descriptions will come along;
 >Sync issue with SDP spec;
 >Beefiness of SIP spec already
 >Some ideas: Separate RFC, Incorporate into SDP revision, Keep it as it is
 >Proposal: Keep it as it is

rohan>  I support all the above proposals #21, #26, #133, #150, & #163.
rohan>  Also I thought that we already tentatively closed #133 at the 51st 
(there were no objections).

 >#73   "responding to held SDP with held SDP"  (interacts w/ #133)
 >If a UA receives an INVITE with held SDP, does it respond with held SDP?
 >Bis-03+ says NO (This has been discussed on list extensively prior to
 >bis-03)  Few comments on resolution: want broader input.

rohan> a UA should respond to held SDP with whatever SDP they would have 
offered.  In other words, you shouldn't respond with held SDP just because 
you receive held SDP (which I believe was the intent of bis-03), but if 2 
IP phones want to go "on-hold" at the same time, I don't see why there is 
anything wrong with that (especially with the proposed "inactive" attribute 
in #133)

 >#146  Re-use disabled streams
 >Spec says that once you've disabled a stream (port zero) you can't reuse it.
 >Result is that SDP size increases as you disable/add streams
 >Why? MUST maintain implicit ordering of codecs
 >Problem is increasing size of SDP--Issue for 3gpp it seems
 >Proposal: Can never remove a disabled stream, But, if you add a new one, it
 >can take disabled streams' "slot" within SDP. Can be totally 
different >media. This keeps ordering without increasing size of SDP

rohan>  the proposal is entirely reasonable.  the only objections where 
philisophical that you should instead use the fid.  I think implementations 
should be able to use either mechanism, so i would change the proposed 
wording to something like this: "MAY NOT remove a disabled stream unless an 
explicit ordering system is used."

thanks,
-rohan 

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