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:[EMAIL PROTECTED]:5061>;tag=71c0d48-0-13bb-28cd57-3284bd2c-28cd57
To: <sip:[EMAIL PROTECTED]:5061>
Call-ID: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
> Sent: Thursday, September 20, 2007 11:59 PM
> To: Eric Burger
> Cc: [email protected]
> Subject: RE: [Sip] INFO
>
>
>
> > -----Original Message-----
> > From: Eric Burger [mailto:[EMAIL PROTECTED]
> > Sent: Thursday, September 20, 2007 3:15 PM
> > To: Stucker, Brian (RICH1:AR00)
> > Cc: [email protected]
> > 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" <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Eric Burger [mailto:[EMAIL PROTECTED]
> > >> Sent: Monday, September 10, 2007 8:08 AM
> > >> To: Stucker, Brian (RICH1:AR00)
> > >> Cc: [email protected]
> > >> 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://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
