Subject: [Sipping] RE: I-D Action:draft-worley-service-example-00.txt

From: "Elwell, John" <[email-masked]>
Date: Thu, 08 Nov 2007 08:52:47 +0000

Dale,

A couple of comments.

Care has to be taken using an SDP answer as an SDP offer. Whilst it
might be acceptable to copy some parts, copying the whole SDP is wrong
because of certain SDP features that are not symmetrical. One example is
MIKEY, where a MIKEY request in an offer has completely different syntax
and semantics from MIKEY in an answer. Another example is the capability
negotiation draft in MMUSIC.

Another concern is how would ICE work? The held UA never receives
candidate IP addresses and ports for the MoH server.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 08 November 2007 04:10
> To: [email-masked]
> Subject: I-D Action:draft-worley-service-example-00.txt
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> 	Title           : Session Initiation Protocol Service 
> Example -- Music on Hold
> 	Author(s)       : D. Worley
> 	Filename        : draft-worley-service-example-00.txt
> 	Pages           : 26
> 	Date            : 2007-11-07
> 
> The "music on hold" feature is one of the most desired features of
> telephone systems in the business environment.  "Music on hold" is,
> when one party to a call has the call "on hold", that party's
> telephone provides an audio stream (often music) to be heard by the
> other party.  Architectural features of SIP make it difficult to
> implement music-on-hold in a way that is fully compliant with the
> standards.  The implementation of music-on-hold described in this
> document is fully standards-compliant, but is simpler than the
> methods previously documented.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-worley-service-examp
> le-00.txt
> 
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in 
> the body of 
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then
> 	"get draft-worley-service-example-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-worley-service-example-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant 
> mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 

_______________________________________________
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: "Michael Procter" <[email-masked]>
Date: Thu, 8 Nov 2007 07:03:35 -0800

Hi Dale,

I have a question about your draft (and am following John's lead in
posting to sipping).  The alternative message flow you outline in
section 2.4 seems similar to the 'old' Music-on-Hold flow described in
draft-ietf-sipping-services-examples (version 11 and earlier).  In fact,
it seems like the variation mooted in this post from Venkatesh:
http://www1.ietf.org/mail-archive/web/sipping/current/msg12180.html

Paul Kyzivat identified a couple of issues with it here:
http://www1.ietf.org/mail-archive/web/sipping/current/msg12181.html

None of those seem to be killer reasons, but the next version of the
Service Examples draft changed the approach to be REFER-based.

Are the reasons that caused the Service Examples draft to drop this flow
still pertinent to your draft (they may or may not be, and I'm not sure
I know all the reasons anyway).

Even if they are still pertinent, is your draft aiming to document
current usage (as encouraged in BLISS), to aid interoperability?

Michael

---

From: [email-masked]
Date: Sun, 11 Nov 2007 13:23:20 -0500

I was originally expecting this to be a matter for BLISS, but due to
the existence of draft-ietf-sipping-service-examples, it probably
better belongs here.

   From: "Michael Procter" <[email-masked]>

   [i]s your draft aiming to document current usage (as encouraged in
   BLISS), to aid interoperability?

My driving purpose was to document a usage so that my company could
point to the document and demand that phone vendors implement MOH
support.  It turns out that even some of the most popular phones
assume a central switch (that is, a B2BUA) that handles MOH by
detecting that the call has been put on-hold and inserting the MOH
directly.  Since our company's architecture is a genuine proxy, we
need MOH support in phones.

The first variant I proposed is very close to (and was derived from)
how Snom phones implement MOH, which is very workable in our
deployments.

After re-reading that message, it looks like my second variant is
exactly what Venkatesh proposed.

The second of his objections seems to be valid.

Philosophically, that objection and the one I mentioned in
http://www1.ietf.org/mail-archive/web/sipping/current/msg11038.html
point to a design problem with SDP: The answer is not constrained to
be a subset of the offer.
While the usage of the m= lines is (largely) controlled by the
offerer, the usage of the payload numbers is controlled by the
answerer.  So there is no way for a UA to "delegate" composing an SDP
ansewr to another UA, because there is no way to constrain what the
delegatee can use in his SDP.

Hmmmm...

Maybe Bob can "mark off" any payload numbers that the MOH server
should not use by showing them as assigned to a bogus codec?

I dislike the REFER technique because it affects the "other end"
identification presented by the remote UA.  But it may be the best
scheme that is compliant.

   From: "Elwell, John" <[email-masked]>

That's true.  But as far as I can see, the second variant does not
transform an answer into an offer, and so should not have these
problems.

This is a strong argument against the first variant, but seems to be
avoided by the second variant.  (This opinion is based on looking at
the overview of draft-rosenberg-sipping-ice-00.)

However, I see that ICE presupposes that that the UAs can pass
re-INVITEs or UPDATEs to revise their media contact addresses.  The
MOH implementation would have to be able to pass these through, or
perhaps could just deny them.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 11 Nov 2007 22:49:35 -0500

IMO the prohibition against reusing a payload number for a different 
codec seems excessively restrictive. I've never heard any explanation 
for why it is imposed. I guess there is a reason briefly at the time of 
changeover because it isn't synchronized with the signaling of the change.

It might be reasonable to relax the rule. BUT, I guess that wouldn't 
help the problem here.

	Paul