RE: [Sip] My two cents on the INFO question

[Hadriel Kaplan <[e-mail]>]

Jonathan,
Thanks for the feedback - comment inline...

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[e-mail]]
> Sent: Sunday, December 02, 2007 11:00 PM
> To: IETF SIP List
> Subject: [Sip] My two cents on the INFO question
>
> I personally do not think there is a good definition yet of what the
> problem is that we are trying to solve.

Huh.  I thought that was clear.  Sorry if the draft wasn't clear on that.  We currently have an in-invite-dialog method defined (INFO) that many people use, but it's "broken" because it's missing a standardized way to negotiate or discover supported uses for INFO, a standardization process for defining packages for it, and signaling what package the specific INFO request is carrying/notifying.  That's the problem draft-kaplan-sip-info-events is trying to address.

Whether INFO actually needs to be fixed or instead needs to be abandoned is almost a separate issue.  Is that what you're asking?

At the last IETF you said "we should work on things that are broken in the real world".  DTMF is broken in the real world (sometimes), except right now SBCs "fix" this issue to make it interop.  I don't mind them doing that forever, but even fixing it is fraught with problems.


> There has been lots of general discussion about INFO usages but for the
> most part, DTMF is the only real concrete one that has come to the
> table. My big worry is that the DTMF "problem" is in fact much bigger
> than just adding negotiation to INFO. Indeed, in a very real sense,
> defining a new INFO package and INFO framework will just add yet ANOTHER
> mechanism to the list of things standardized for DTMF (2833, KPML,
> existing non-standard INFO, unsolicited NOTIFY, and now INFO package).

My short answer to your question is "I don't know".  I don't know if standardizing INFO will succeed in attracting implementation by vendors which currently do non-standard in-dialog INFO/NOTIFY for DTMF.  I don't know if this will reduce the interop issues.  I don't know if given enough time, those vendors would go implement KPML anyway.

I *do* believe that there is a price to be paid for KPML above that of INFO, and that price will keep people doing INFO/NOTIFY.  I *do* know there is a need for signaling-plane DTMF.  I *do* know that there is no current standard for INFO-based DTMF.  I do believe that if we do not offer a standardized way of doing DMTF in INFO, then the set of {2833, KPML, application/dtmf-relay INFO, application/dtmf INFO, application/dtmf-event Notify, etc.} will not get smaller.  The hope is it gets down to {2833, KPML, INFO}.

We can piss up a rope and outlaw the most popular way to do signaling-plane DTMF.  Or we can account for gravity.


> What are the actual use cases where DTMF-over-INFO is the 'right' thing?
> The only one I've seen mentioned was the 323 gateway case. Are there
> others? Is that the only use case that this whole mess would actually
> address?

DTMF-over-INFO is the 'right' thing to do when the other side asks to receive it.  You'd ask to receive it if you're a UA in the call path that wants to get DTMF in an Invite dialog in the signaling plane.  It's not just h323.  It's MGCP too.  And apparently a bunch of app-servers and PSTN gateways that continue to use INFO/NOTIFY today.


> Another big worry is that, if we did have this INFO framework, we would
> be adding another mechanism to an already-long list of ways to handle UA
> to UA signaling. Is it clear what the different areas of applicability
> are for rfc3265 vs. setting up a separate control session vs. new
> methods vs. UPDATE w/ headers vs. the new INFO framework? I don't think
> is clear at all.

I think that could be worked on, with one extreme result being to limit INFO to only DTMF.

-hadriel


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip