Hi,
>>1. INFO for keep alive? Thatıs a new one. Everyone I
know uses
>>OPTIONS. Oh well. Maybe we should resurrect the PING
method.
>
>Well, you don't know Jack then. Jack uses INFO. :P
>
>Seriously, there are people out there using it this way.
No
>negotiation is required. I'm not defending it, I'm just
>letting you know that there are a number boxes out there
>hammering away with INFO requests to see if a dialog is
still
>active. Ask around and I'm sure you'll find people who
have
>at least seen this done even if they don't generate the
>requests themselves.
>
>Honestly, I think we should all be using RFC-4028 and
not
>OPTIONS or INFO for this purpose. If you want to put
that in
>your draft, I'll happily support that.
I am not defending the usage of INFO for this either, but I
see no reason why we should forbid things which are
absolutely harmless. Let's focus on real issues instead.
>>2. INVITE discussion is a non-sequitur. INVITE
fully specifies a negotiation framework. INVITE without SDP
is an invitation
>>for you to start the negotiation.
>
>Ok, so I send you an OPTIONS or an INVITE first to see
what
>content-types/mechanisms you might support for DTMF
>transport. You tell me what you support, and then I use
that
>mechanism (might be INFO digits). What's the difference?
If I
>send you something you don't like or understand you can
>reject it. Sounds like a negotiation framework already
exists.
>
>>
>>3. The semantics of the media are totally orthogonal
to the INVITE negotiation. C.f. the LONG discussion on
P-Asserted-Service.
>>
>>4. The semantics of an INFO body is critical. The
stack needs to know how to process the body or where to pass
the message to.
>>Right now, there is no mechanism for doing that.
Content-type does not work.
>
>So where do you think the stack sends SDP content types?
>You're making the claim here that the content-type can't
be
>used to determine the semantics, or that the stack can't
>figure out how to handle it and must just simply choke
and
>die because it was conveyed in an INFO instead of an
INVITE.
>I'm probing to find the justification for that
assertion.
I agree.
Regarding the question how to know where to pass the message
internally. I think that is an implementation issue, and you
have to deal with that also if using other mechanisms.
>>5. "Just write it down": Agreed, and there
has already been a framework for doing INFO negotiation
(Dean's document). I
>>was about to go there, until I realized that it
would be identical to SUB/NOT.
>>
>>6. Rough work group consensus was NOT to create an
INFO negotiation mechanism. If you can convince the chairs
otherwise, I'd
>>be happy to submit a negotiation mechanism.
>
>I don't remember it going down quite that way and I was
at
>the mic expressing support. Perhaps I misunderstood the
>question that prompted the vote, but I interpreted it as
>meaning we didn't think one was NECESSARY. Big
difference in
>my mind. Acknowledge the uses as they exist today,
encourage
>people to look elsewhere for the future. I thought that
was
>what we said at the last meeting. You're arguing that
INFO w/
>DTMF is broken because there's no negotiation mechanism.
>Sending DTMF with a given content-type and expecting the
>other side to reject that content type if it does not
>understand it is a basic tenet of SIP. You can clearly
tell
>if the other side understands or not unless it is not
paying
>attention to what it's being sent.
My understanding of what was decided at the mic was that we
were going to continue the discussions. Eric's draft was
going to be used as base for the work, but that does not
mean we agreed to everything which is said in the draft.
>>7. The argument that we have to extend INFO to do
negotiation because
>>we need to protect the existing INFO-based DTMF
implementations is
>>totally bogus. If we create a negotiation
mechanism, those existing
>>implementations have to be fixed.
>>If they have to be fixed, any reason not to fix them
with something
>>that already works and won't suck down work group
and RFC Editor time?
>
>I'm not asking to fix anything. Honestly, I think the
vast
>majority of implementations are moving on to 2833/4733
to
>convey DTMF digits and to a great extent that makes the
>discussion somewhat moot in my mind.
We seem to be concentrating on DTMF, but I think we should
be more generic.
The question is whether we should allow INFO as a mechanism
(limited, maybe) to transport information. The answer seems
to be "No, you can use subscription events.". But,
there are reasons why people don't want to use that.
Regards,
Christer
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
