Session Initiation Protocol Service Example -- Music on Hold
draft-worley-service-example-15

Delightful document although I take issue with the very first statement:

>   The "music on hold" feature is one of the most desired features of
>   telephone systems in the business environment. 

I get pretty annoyed by it. Especially bad music on a short loop with poor quality audio. :-)

---

A number of key fields have not be filled in to the data tracker. Of particular importance is the "IETF consensus" field

A couple of very minor, non-blocking comments; please consider them, and there's no need to reply.

-- Section 1.1 --

Much discussion of the intended status, and why this isn't a BCP or whatever, may have been useful during the development of the document and its review by the community and the IESG, but probably doesn't have archival value.

I suggest adding the last paragraph, minus the word "however", to the end of the second paragraph of Section 1.  I suggest moving the second paragraph to be a new third paragraph of Section 1.  That will leave the first paragraph, to which I suggest you add a note to the RFC Editor to remove this section on publication.

-- Section 6 --

The citations to mailing list messages are interesting.  I'm not sure I've seen it done before, but I think it's probably useful.  That said, I think it'd be more useful if the references contained URIs for the messages, rather than just the message numbers.

I'd like to understand why this document is not being put forward as either Proposed Standard or Experimental. This document does describe protocol. It may be updated in the future if there are certain parts of the protocol exchange that need to be changed or clarified. It might become the one and only standard way that people do MOH. It doesn't matter that there are other ways to to MOH; it's that this is one good (maybe the best) way to do it. Section 1.1 doesn't really explain why you didn't go for PS or Exp. (I certainly agree that this ought not have been BCP.)

If it goes forward as Informational, the world doesn't end. But it seems like a non-ideal choice.

I agree with Barry that either way, 1.1 probably doesn't need to be in the final RFC.

- abstract: Music on hold? Sorry, but yuk, so "most desired"
is not something I find credible unless you care to say who
desires it any why. "Fully effective" is also just
marketing. And "standards compliant" is also an odd thing to
say - why should we note that?

- I recently used some concall service that told me "if you
don't want the music, hit 1" which is nice. If that isn't
the content of someone's really dumb patent, it'd be a
service to humanity to include that feature here.

- The security considerations are very thorough, thanks.
However, it'd be better if you said "this will break any
security setup for the call unless the MOH and executing UA
are in the same domain and indistinguishable from the remote
UA's perspective." It'd be a real shame for this feature to
be something the precluded introducing some e2e security
into SIP. (This isn't a discuss only because it seems e2e
security for SIP calls seems mythical right now and this
is informational. If this does need to be standards track
I might promote this to a discuss calling for there to be
a way to ensure that MOH doesn't weaken whatever
security is in place for the call).

I agree with Adrian's note, as MoH is my most unfavorite feature, reminding me of the time and money I am wasting due to the lack of call center capacity at the called party.

Don't some codecs require "speech on hold"?

I neither require nor anticipate any change based on the above comments.

I think the text in the introduction about why people want on hold music is better than the text in the Abstract; I mention this because several other ADs commented on the abstract text, which I too found to be excessively exuberant on the topic of how much people like on hold music.   No need to change it unless you take all this whining to heart.

I agree with Pete that if this document lives up to its sales pitch, it ought to be either experimental or proposed standard, not informational.   The motivation for calling it informational seems to be that it isn't intended to supersede other methods, but that's not a reason for it to be informational.   That's just a reason not to put "Obsoletes RFCxxxx" on the title page.   I'm curious to know if you talked this over with Richard, or if it just passed under the radar.

In section 2, the links to RFC 4566 and RFC 3264 are broken, but the link to RFC 6337 is working.    I don't know what happened here, but you should fix this in your source so that they all work, assuming it's not a bug in xml2rfc.

In section 2.5, it looks like what's happening here is that Alice has transferred the call to Carol.   Is that correct?   If so, you might want to say that.   I suppose a reader who's experience with SIP will understand this, but it was a bit mysterious to me, and I think saying what is happening makes it clearer.   Not all readers are wizards.   (If I _knew_ that I'd understood it correctly, I would not have made this comment; the problem is that the text does not confirm my supposition, so I don't know whether or not it is correct.)

Actually, reading section 2.6 suggests to me that I haven't got it right.   I think 2.5 and 2.6 would benefit from an explanation of what user action triggered the described protocol behavior.

Section 2.7 has another broken external reference, to RFC 5245.   It's possible that I've missed other such references on the way through the document—if you figure out why this is happening, you should probably check for instances I've missed.

You also have several broken cross-document section references in 2.8.1.   This suggests to me that it's the tools HTML reader that's at fault here, but if you are using xml2rfc, it would be good if you could use the xml2rfc technique for doing cross-document section references, so that these do the right thing when the reader clicks on them.   If you aren't using xml2rfc, this can be left to the RFC editor.   BTW, the link to section 6.3 of RFC 3264 that immediately precedes the 2.8.3 section header is rendered correctly, so one way to address this comment would be to reformat the other cross-document section references so that they look like this one.   Also, it occurs to me that the broken references elsewhere in the document may be broken because there is no whitespace before the opening square bracket: foo[RFCxxx] rather than foo [RFCxxx].

The conclusion of section 2.8.1 is a bit unhelpful.   It seems to me that the implementor of a user agent can't really know whether or not the solution described in later portions of section 2.8 is needed, and indeed there's no way to tell from the protocol either.   So the document should either recommend always implementing the solution you describe here, or shouldn't recommend it.   It seems to me that you, an expert in the field, think that this hack is unnecessary, and are including it merely for completeness.   If that's the case, it would be good to say so.   It would help to understand why the requirement you are working around here was stated in the first place.   If you really can't be sure this hack is not required, then it should probably be required, even if in most cases it's unnecessary.

In 5.2:
   The executing UA and the MOH server will usually be within the same
   administrative domain and the SIP signaling path between them will
   lie entirely within that domain.  In this case, the administrator of
   the domain should configure the UA and server to apply to to the
   dialog between them a level of security that is appropriate for the
   administrative domain.

You have a doubled "to" toward the end of the fourth line.

All in all a very readable and understandable document—thanks for doing it!