Subject: [Sipping] Some comments on draft-camarillo-sipping-early-media-01.txt

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 13 Mar 2003 20:30:30 -0000

Some fairly minor comments that need to be applied to this document if it progresses with the current text in any of these areas.

A question over and above these comments - is the intent of this work to result in a standards track document or an information document? Which of those will affect whether some of the standard clauses are needed or not.

regards

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked] 

1)	General. Can we stop using the term ringback tone, as these is not a standard definition elsewhere and certainly in the PBX world means something entirely different. I would suggest an appropriate term is "ringing tone" and the appropriate reference for definition of that term ITU-T Recomendation E.182 "Application of tones and recorded announcements in telephone services" and the technical characteristics of such a tone is defined in ITU-T Recommendation E.180, "Technical characteristics of tones for the telephone service".

2)	Section 1, 3rd (last) paragraph, suggest reference back to section 12 of RFC 3261 for the term "early dialog", maybe as part of a new definitions clause if you do not wish to do it in the text itself.

3)	Section 2, 3rd paragraph. "early" appears in quotation marks here, but not elsewhere. Lack of consistency.

4)	Section 2.1. This is a long piece of text for which we discover at the end that this section (including 2.1.1) that it is describing a problem that is outside the scope of the document. Perhaps we could try to develop a shorter way of getting to that conclusion.

5)	Section 2.1, 6th paragraph (just before the end of page 4) - I did not understand the distinction being made by the phrase "and the caller starts speaking as well" to the rest of the sentence. Can you explain further.

6)	Section 2.2, 2nd paragraph. Two uses of the word "supposed" in "is supposed to generate" and "is supposed to play". I think this is too strong a word for something that is entirely up to the design of the implementation as being described. I would substitute something like "can generate" and "can play".

7)	Section 2.2, 4th paragraph, top of page 7, text "With this in mind, a UAC should develop...". Is this meant to be "SHOULD", i.e. one of the RFC 2119 terms.

8)	Section 2.2, 4th paragraph, numbered list items 2) and 3) include word "response" after "(Ringing)".

9)	Section 2.2, 5th paragraph through to end of section. Here we have a paragraph (no indent) starting  "Note, however..." followed by an indented one starting "Note that..." followed by one (no indent) starting "Note that...". I am confused by the relative status of these paragraphs to each other and to the rest of the text.

10)	Section 3, 1st paragraph, not a comment that requires fixing, but we have a dependency to the Join draft which will need to be finished before or at the same time as this draft.

11)	Section 3, 1st paragraph, Amend final sentence to read "... by sending a new INVITE request to the URI it received in the Join header field."
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Alan Johnston <[email-masked]>
Date: Thu, 13 Mar 2003 15:17:53 -0600

At 08:30 PM 3/13/2003 +0000, Drage, Keith (Keith) wrote:

<snip>

>10)     Section 3, 1st paragraph, not a comment that requires fixing, but 
>we have a dependency to the Join draft which will need to be finished 
>before or at the same time as this draft.
>
>11)     Section 3, 1st paragraph, Amend final sentence to read "... by 
>sending a new INVITE request to the URI it received in the Join header field."

This entire section is quite confusing.  I think that Gonzalo does not mean 
to reference the Join header field - it has no application in this 
example.  I think he means to reference the To-Join header field proposed 
by Jonathan in the original call package 
(http://www.softarmor.com/sipping/drafts/morgue/draft-rosenberg-sip-call-package-00.txt). 

Also, the reference 5 cited in this section is the Application Interaction 
Framework which again has no bearing on this idea of separate dialogs for 
regular and early media.  Perhaps the Application Component Architecture 
document was the intended reference?

Thanks,
Alan Johnston
WorldCom
sip:[email-masked]