Subject: [Sip] SIP info method - rfc2976

From: "Feldman, Michael" <[email-masked]>
Date: Wed, 10 Jul 2002 07:37:22 -0700

I know this is probably a little late, but....

I do not see why 
the info method is supposed to follow an established signaling path.  It
would be helpful (in my case at least) to send session information to a
third party destination not involved with the SIP call.

section 1 intro:
"It is necessary that the mid-session signaling information traverse the 
post session setup SIP signaling path.  This is the path taken by SIP
re-Invites, Byes, etc..."

it also mentions it in section 2...

thanks,
mike feldman
[email-masked]

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

---

From: Gordon Ledgard <[email-masked]>
Date: Wed, 10 Jul 2002 10:53:40 -0400

If INFO didn't follow the same rules as the rest of the SIP traffic,
it would require its own whole set of procedures to validate it and
make sure it belonged there.

Is your "third party destination" also a SIP endpoint? Why is it in
the conversation? Who says so? I believe what you are looking for can
be solved via a whole slew of other mechanisms besides SIP. 

And yep, you're a bit late. :)

Gordon Ledgard

-----Original Message-----
From: Feldman, Michael [mailto:[email-masked]]
Sent: Wednesday, July 10, 2002 10:37 AM
To: [email-masked]
Subject: [Sip] SIP info method - rfc2976

I do not see why 

section 1 intro:

thanks,
mike feldman
[email-masked]

---

From: Adam Roach <[email-masked]>
Date: Wed, 10 Jul 2002 12:05:06 -0400

The problem is that there is a widespread misconception that
you can do whatever the heck you want with INFO, and still
call what you're doing "SIP."

In all liklihood, you're trying to accomplish a task that
falls in one of the two categories:

a) Something the SIP working group has thought of, and
   has a solution to, or

b) Some useful application that we haven't thought of yet

So, instead of trying to overload INFO (which is looking like
an increasingly bad idea as time goes on), you'd probably be
better starting on sip-implementors (see the automatically-
inserted note at the end of this message), and describing your
application. If it falls into category (a) (and I suspect it
does -- we've been at this for a while, and have a ton of
tools), then someone can point you at the relevant RFCs/drafts.
If it falls into (b), then we can start working on the tools
you need to implement your service.

/a

> Sent: Wednesday, July 10, 2002 9:37
> To: [email-masked]