Paul, Some questions inline.
Many thanks Regards, -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat (pkyzivat) Sent: Thursday, September 18, 2008 6:23 AM To: Iñaki Baz Castillo Cc: [email protected] Subject: Re: [Sip-implementors] Music-on-hold proposal Iñaki Baz Castillo wrote: > El Miércoles, 17 de Septiembre de 2008, [EMAIL PROTECTED] escribió: >> I've got an Internet-Draft that describes the best way that we (the >> sipX PBX project) have found to implement music-on-hold. I'd like >> feedback from the implementor community. > > Hi, it seems really interesting. Just a question: > > Why so strange parameter name in Contact?: > +sip.rendering="no" > Is it usual a parameter name begining with "+" and containing a dot > "." in other parameters? You obviously haven't yet found callerprefs. Check out RFCs 3840 and 3841. (I predict that you will hate them. Everybody does, including the authors.) [RL] I find RFC3840 falls into "Core SIP Specifications" of draft-ietf-sip-hitchhikers-guide, why do you think everybody hate them? Do you mean it's not widely used in real world? > Also, isn't there a better way to indicate that the UA is putting the > call on hold? I mean in SIP headers, of course, since there is not SDP. There is a philosophy of describing behavior rather than named features. "Hold" is a feature which can be implemented with many different behaviors. The basic approach to hold uses a=sendonly/recvonly/inactive to adjust how media flows, but the use for hold is not unique. I didn't remember this parameter. :-( It is technically a "callee-capability". IMO using it for rendering is a bit of an abuse, since it is trying to describe what it is doing rather than what it is capable of doing. Even so, it doesn't mean "hold". I'm not certain that it really provides any value in this case. > Is the Contact header the best place to indicate it? (maybe yes, I just ask). I doubt you want to know all the history. But it starts with 3840/3841. [RL] I am interested in this history, if it's inappropriate to discuss in this mail list, please unicast me.thanks Paul > Best regards. > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
