Subject: Re: Some initial queries/comments on draft-ietf-sip-183-00.txt

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 16 Nov 1999 16:47:04 -0600 (CST)

Sorry I've not been responding recently. I've been somewhat out-of-pocket
for the past six weeks. I wish I could have been at the DC meeting...

>1) you don't make clear which pieces of this are intended to be specific to
>the 183 response message and what pieces are intended to be generic. For
>example, it would seem that the "Session: media/qos/security" header is much
>more generic. In the abstract and introduction, it might be best to say
>you're making TWO extensions to SIP, the Session header, and the 183
>response.

This is a very good point; the title of the draft should probably
reflect this as well.

>4) I know this may be a can of worms, but if we ever want to allow multiple
>SDP bodies in SIP messages it would behoove us to ensure that headers that
>refer to body part treatment can explicitly say WHICH body instance they
>refer to.

We had breifly debated making this header a content header. The obvious
advantage is that it fixes the problem you point out. Unfortunately,
it also ties protocol behavior to headers that are arguably part of the
body -- and I beleive there is a strong consensus that the body shouldn't
have an effect on the protocol (which is the primarly flaw in my original
draft).

Can you think of a palatable syntax that gets around both problems?

>5) the MUSTs in section 4.2/4.3 seem a bit strong. Nothing breaks if the
>sender is slow or sloppy at stopping; the user might get some mixed audio or
>be annoyed though. While I can't off the top of my head think of any
>positive use for the continued transmission (maybe the "call is being
>monitored" beep tone...") I'd like to hear why such strong prohibition is
>called for.

The concept when I originally put that together is that some (most?)
simple end-devices will have no means of mixing multiple RTP audio
streams.

>There is also the philosophical question of what actually
>constitutes "temporary" media, especially in the case where the SDP
>describing the "permanent" media is identical to the SDP describing the
>"temporary" media.

This occured to me too late to make it into the revised draft.
Perhaps the media should be continued if the SDP matches?
(Otherwise you get a brief gap between the 200 and the ACK).

>6) Section 4.4, second paragraph. While I see that 183 may not be
>appropriate for ringing, forwarding, or queued (since we have other
>responses for these), the used of Session: media may be perfectly
>appropriate. Is this just another instance of not becing clear about the
>relative independence of the Session: header and the 183 response?

Yes; the two concepts are supposed to be perfectly orthagonal.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA