Regarding usage of INFO for keep-alive, below is trace
captured on a machine
running a very popular IM/voice client. This client sends an
INFO to its
server every 3 minutes.
The funny thing is that the client supports session-timers
(notice
Supported: timer in the trace) but it still uses INFO
instead of reINVITE or
UPDATE for keep-alive 
Transmission Control Protocol, Src Port: 1571 (1571), Dst
Port: 5061 (5061),
Seq: 3269, Ack: 3321, Len: 384
Session Initiation Protocol
Request-Line: INFO
sip:XXX.XXX.XXX.XXX:5061;transport=tcp SIP/2.0
Message Header
From:
<sip:YYYYY XXX.XXX.XXX.XXX:5061>;tag=71c0d48-0-13bb-28cd57-32
84bd2c-28cd57
To: <sip:YYYYYXXX.XXX.XXX.XXX:5061>
Call-ID: 71c0d48-0-13bb-28cd57-51c7c502-28cd57XXX.XXX.XXX.XXX
CSeq: 3 INFO
Via: SIP/2.0/TCP
XXX.XXX.XXX.XXX:5051;branch=z9hG4bK-28cd57-9f621dd0-31f65a45
Max-Forwards: 70
Supported: timer
Content-Length: 0
Thanks,
Raj
> -----Original Message-----
> From: Brian Stucker [mailto:bstuckernortel.com]
> Sent: Thursday, September 20, 2007 11:59 PM
> To: Eric Burger
> Cc: sipietf.org
> Subject: RE: [Sip] INFO
>
>
>
> > -----Original Message-----
> > From: Eric Burger [mailto:eburgerbea.com]
> > Sent: Thursday, September 20, 2007 3:15 PM
> > To: Stucker, Brian (RICH1:AR00)
> > Cc: sipietf.org
> > Subject: Re: [Sip] INFO
> >
> > 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.
>
> >
> > 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.
>
> >
> > 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.
>
> >
> > 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.
>
> Whether this document exists or not will not affect
> INFO-based DTMF implementations. The horse is out of
the barn
> and way down the road on that one. You've made some
> assertions in your arguments that I believe need some
> substantiation. You've said that the content-type is
not
> enough to figure out what is going on at all. I
disagee. I
> think a content type that says "I'm sending you
DTMF digits
> in a particular format" is every bit as robust as
the
> content-type that conveys MWI for instance, and a heck
of a
> lot more specific than SDP is. We have done quite well
with
> SDP for some time in getting things to work, so I don't
> understand why simply writing down: hey, this
content-type
> means DTMF digits is not a valid way forward to closing
the
> books on that implementation. We can even say things
like
> "please don't do this in the future" but
unless we can
> clearly show WHY people shouldn't do this in the future
that
> uses logic that can also clarify the things that we DO
want
> them to do in the future, I don't see how this can be
successful.
>
> It appears arbitrary to say DTMF in INFO is bad because
it
> relies on content-type settings to identify it as such
when
> we do not require a P-Asserted-Service header in every
INVITE
> to clarify the SDP that lies within.
>
> I think you may be confusing my questioning of your
arguments
> as a declaration of support for using INFO for a
particular
> purpose. I honestly don't care if another INFO is ever
> generated by any SIP stack anywhere ever again for any
> purpose personally. I'm looking for consistent
arguments that
> can be applied to problems outside of INFO so when the
next
> bad idea (tm) comes along we can clearly point to this
> document and say "you're trying to do X which we
can clearly
> show is bad and does not align to the things we think
are
> good." I haven't read such an argument yet.
>
> >
> > 8. Who in their right mind would use KPML for keep
alive?
> > You can always subscribe to anything with an
expires of zero.
> > It is still silly in any event [sic].
>
> True. I completely agree. I didn't write that last
statement
> correctly. I was intending to point out that INFO was
being
> used this way. KPML has nothing to do with it.
>
> >
> >
> > On 9/10/07 11:46 AM, "Brian Stucker"
<bstuckernortel.com> wrote:
> >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Eric Burger [mailto:eburgerbea.com]
> > >> Sent: Monday, September 10, 2007 8:08 AM
> > >> To: Stucker, Brian (RICH1:AR00)
> > >> Cc: sipietf.org
> > >> Subject: Re: [Sip] INFO
> > >>
> > >> Brian Stucker Says:
> > >> I'm not really sure what your point
was
> > >> here unless you are against people
> > >> writing down a common way of using
> > >> a protocol amongst themselves
> > >>
> > >> Actually, I have no problem with
"people writing down a
> > common way of
> > >> using a protocol". One would offer
that is the work of the IETF.
> > >> However, the key phrase I have a problem
with is, "amongst
> > >> themselves." The IETF makes
protocols for everybody, not
> > just members
> > >> of the garden club. The garden club can
do whatever they
> > want inside
> > >> their garden. The IETF has no right nor
interest in
> mandating what
> > >> goes on inside their garden.
> > >
> > > True, but it's not a club. Those disclaimers
are to limit
> > reproduction
> > > of the material by other SDOs without
permission. You don't
> > have to be
> > > a member of the garden club to use the
protocols written by
> > the garden
> > > club, such as they are. Whether you want to
or not is
> > another matter
> > > entirely.
> > >
> > > [SNIP]
> > >
> > >> In my mind, INFO for DTMF falls into the,
"it is not an Internet
> > >> protocol, but you can do whatever you
want in your
> playground, so
> > >> long as your fences are good and you will
still play with
> > me. P.S.,
> > >> do not claim you are using Internet
protocols, because you
> > are not."
> > >
> > > Only because they happen to not be written
down as an IETF
> > document,
> > > which, as I suggested earlier, may be the
solution to the problem.
> > >
> > >>
> > >> P-Preferred-Service is an example of
something that falls
> > into "the
> > >> toxic substance that will bleed through,
so do not even think of
> > >> using it" category.
> > >
> > > So then I would be most interested to hear
your thoughts on the
> > > following:
> > >
> > > The first sentence in section 2 in your draft
states:
> > >
> > > "There is no programmatic way of
determining what
> > the content
> > > of an INFO request means."
> > >
> > > You could say the same is true for an INVITE.
To the
> 'User-Agent's
> > > point of view, an [INVITE] just appears'.
Without a negotiation
> > > mechanism such as SDP, is this INVITE
conveying an
> > conference call, a
> > > user-to-user gaming session, or what? We
can't programmatically
> > > determine what an INVITE with no SDP means.
So if I'm
> > following your
> > > argument here wrt INFO, the analogous
solution would be to
> > deprecate
> > > INVITE unless it always has SDP.
> > >
> > > But wait, there's more... Again, using your
line of thought
> > for INFO,
> > > SDP may not be good enough:
> > >
> > > "However, as we learned in the
messaging community [7],
> > > relying upon the MIME type alone is not
sufficient to
> determine the
> > > context of the message. Clearly, as shown in
the previous
> paragraph
> > > [which describes using the MIME type of an
INFO as a negotiation
> > > mechanism], the message content relates to
the message context.
> > > However, it is quite easy to imagine
situations where the
> > same content
> > > type has multiple meanings for a User
Agent."
> > >
> > > So if the content relates to the message
context, and the
> > content and
> > > type can be ambiguous, such as the INVITE
contains SDP,
> or the SDP
> > > contains an audio stream (is it a conference
or is it a podcast or
> > > what) or worse, SDP that contains content
types that are not
> > > well-known, then clearly SIP and SDP are not
enough to correctly
> > > identify what the User Agent is to do with
this request. Hence, a
> > > mechanism such as P-Preferred-Service rears
it's ugly head.
> > >
> > > As a result, if I understand you correctly,
rather than
> correct the
> > > negotiation problem (more like just write it
down because
> > it's already
> > > being neogitated out there in the wild in
many cases) and
> > let the UAs
> > > deal with it, you'd rather deprecate the
whole thing in favor of
> > > something else. Correct?
> > >
> > > Also, your list of examples is missing one
usecase that KPML
> > > definitely does not address (but session
timers does): INFO
> > is used to
> > > detect if a call is still alive.
> > >
> > > Cheers,
> > > Brian
> > >
> >
> >
> >
> > 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://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol Use
> sip-implementorscs.columbia.edu for questions on current
sip
> Use sippingietf.org for new developments on the
application of sip
>
_______________________________________________
Sip mailing list https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
