[moved to SIP list at the request of the Chair] In line.
On 7/16/07 7:43 AM, "Christer Holmberg (JO/LMF)" <[EMAIL PROTECTED]> wrote: > > Hi, > > I have a number off issues with the draft, and I think it's extremely > un-objective. > > - I disagree with the statement in chapter 1 regarding the "context for > interpreting". The context is associated with the content type. > > - I disagree with the statement in chapter 1 regarding not negotiation > method. You can indicate what content types you support. > > - I disagree with the stamement in chapter 1 saying that something would > work only in limited or controlled networks. I am not really sure what a > controlled network means in this context, though. Of course some people > may have implemented something which only works between certain nodes, > or in certain networks, but that's a separate issue (and not even > specific to INFO). See the trivial example where this breaks down that I just posted. See also RFC 3458 for a few examples of how media type alone is not sufficient for determining why one is receiving the content. > - I don't understand the statement in chapter 1 saying "Likewise, a > routing proxy, such as the 3GPP IMS S-CSCF, will not expect to receive > media server control messages.". A routing proxy most likely wouldn't > care about media server control messages, so I don't understand the > "will not expect" thing. By expect, I meant from a traffic load perspective. Clearly the S-CSCF will be ignorant of most messages. > - I don't understand the statement in chapter 2, saying "a DTMF digit > type could be for user stimulus, post-dial digit collection, simple > transport of a > digit (no signaling context), or a mistake.". How is that specfic to > INFO? I can press a DTMF button "by mistake" no matter what mechanism I > use to transport it... The mistake here is the INFO, not the digit press. See the trivial example. That is an example of a mistake. > Now, these are issues Eric and I have agree to discuss off-line in > Chicago. > > I also have comments (some of which I've already given before) on > Jonathan's statements: > >> 1. confusion resulting from DTMF being sent in rfc2833 and INFO > > I believe you have the same problem with KPML, and the solution is to > use only one mechanism to send the DTMF. And we agree :-) >> 2. no way to signal whether the far end wants to receive DTMF via INFO; > > The far end indicates what content types it supports for this session. > >> it may be getting it via rfc2833 and that is fine for most cases > > Fine. Then you don't indicate support for the content types used with > the INFO solution See trivial example of why this CANNOT work. >> 3. proxies seeing INFO message load when they don't care about it > > That is a potential issues, yes, but you MAY end up with exactly the > same proxy path using KPML. It depends on the network architecture and > routing mechanisms. Yes, but at least KPML has a *few* throttling mechanisms, including digit maps, the potential for intermediaries collapsing events, and the generic RFC 3265 throttling mechanisms. INFO has *NO* throttling mechanisms. > And, with KPML you will end up with multiple dialogs. Whether that is a > problem or not is for each one to decide, but I think it's fair to > document that, and possible issues related to it. Why we have multiple dialogs was beaten to death by RFC 3265. What part of unsolicited subscriptions is still OK? >> 4. no way to pass digit maps so that you end up sending every digit in > its own INFO or guess at the maps, so its inefficient > > That is a limitation, yes, but it may not be required by everyone. And, > it could be solved using a content type parameter. > >> 5. security issues in case the DTMF is containing calling card info or > credit cards - rfc2833 along with SRTP is much more secured > > The security issue is not specific to DTMF, and using that argument we > should send everything sensitive on the media plane. Also, in some > environments the security may be provided other ways. > >> and so on. > > I don't have anything against documenting and discussing different > issues. But we shall be fair, and look at issues with ALL alternatives. > > The document doesn't say anything about WHY people are using INFO in the > first place. It only says that "people think it's an IETF way of doing > things", without considering that fact that there could be issues with > other mechanisms why people are not using them. Please enumerate why people use INFO, other than the RFC 4722, "It was the only thing available" argument. Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
