Inline
Gilad Shaham wrote:
Hi,
Here is another major problem with INFO - there is no header that states
the purpose of INFO.
If the conte-type is correct, the payload is a DTMF digit. No needs for
a special header.
The event header in subscriptions helps identify an event package.
Therefore an implementation can easily detect if this event package is
supported or not.
You can state in the Accept header that you support the content-type for
the DTMF paylod ( application/dtmf or application/dtmf-relay )
With INFO it is much harder to detect the purpose of
this INFO message. Currently AFAIK the content-type in INFO implicitly
denotes this.
So, why is harder ?
If you are aiming towards a solution that keeps INFO for more usages, I
would say that we need to resolve this issue first.
I do not see any issue here
I also think it would be a burden on implementors to do both KPML and
INFO. Wouldn't it be easier for the implementors that did INFO to switch
to KPML instead of the entire industry doing both?
INFO is very easy to implement. So I dont't see any problem to keep the
INFO implementation
until KPML is adopted. Or maybe keep both.
Gilad
Diego B
-----Original Message-----
From: Christer Holmberg (JO/LMF)
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 12, 2007 3:56 PM
To: Gilad Shaham; Rafferty, James; Steve Langstaff; Spencer Dawkins;
Robert Sparks; Jonathan Rosenberg
Cc: [email protected]
Subject: RE: [Sip] INFO message belongs only to INVITE dialog usage?
Hi,
Are we aware of real-life problems with using INFO for DTMF (or
whatever
else it's used for)? People have been doing it for a while (if we
wanted
to restrict something, it should have been done years ago...), it's
fairly simple to implement - and it seems to work.
Do we need DTMF via INFO for some kind of functionality KPML (or RFC
2833) does not provide? I'm not aware of such a case.
Regarding 2833, I guess the main idea of sending DTMFs out-of-band (no
matter if you use INFO or something else) is when you send them to an
entity which does not have media access.
One description of a problem with INFO can be found in this
historical
chat:
http://www1.ietf.org/mail-archive/web/sipping/current/msg04455.html
The explanation from the expired draft is as follows:
Under this proposal, a User Agent MUST NOT send signaled
digits or telephone-events using the INFO method if the event
was ever represented as a tone (as media). Only signals
originated as pure signaling MAY generate an INFO method.
Failure to heed this requirement will result in
double-detection of digits/events.
If INFO is used incorrectly by a pair of PSTN gateways (for
example), the source gateway may detect a digit, send an INFO
request which is lost, and retransmit that request. The
target gateway would send the original in-band tone to the
PSTN when the audio media arrives, later when the INFO
arrives, the target gateway would render the same tone again.
It is quite likely that the INFO will arrive after the media
tone has been played (especially if multiple intermediaries
are involved); the same digit would be played out again and
this will frequently cause systems in the PSTN to detect the
same digit signaled twice.
You can always mess up if you use things incorrectly. I don't think
that
is INFO specific.
Regards,
Christer
The only problem is that much of the INFO usages are not defined
in
RFCs, but that's not always the fault of the implementors...
I think the implementors knew this was not standard or at
most in very early draft mode when they implemented it.
Regards,
Christer
_______________________________________________
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
_______________________________________________
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
