Subject: RE: [Sipping] WGLC closed, requesting IETF LC on draft-ietf-sipping-3pcc-00.txt

From: "Roy, Radhika R, ALASO" <[email-masked]>
Date: Tue, 14 May 2002 17:12:24 -0400

Inline [RRR]

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Tuesday, May 14, 2002 3:27 PM
To: Roy, Radhika R, ALASO
Cc: Dean Willis; Sipping (E-mail)
Subject: Re: [Sipping] WGLC closed, requesting IETF LC on
draft-ietf-sipping-3pcc-00.txt

inline.

"Roy, Radhika R, ALASO" wrote:
> 
> Hi, Dean:
> 
> I suggest the following modifications in the text to provide fair
> chances for all possible options:
> 
> Figure 11 - Mid-Call Announcement (Flow 11 - BYE): "How the controller
> can know when to hang up the call is outside the scope of the
document,
> and might have been done through an HTTP message from the media server
> to the controller, for example."
> 
> I like to suggest that the above text of the draft should be replaced
as
> follows:
> 
> "How the controller can know when to hang up the call is outside the
> scope of the document, and might have been done through an INFO
message
> (using SIP) or through an HTTP message from the media server to the
> controller, for example."

I strongly disagree here.

The BCP documents "best current practice" for usage of protocols. There
is pretty broad agreement these days that INFO is *not* best practice
for delivering DTMF or other events to an application server. Therefore,
I see no reason to change the text as it reads.

[RRR] It is *NOT* about delivering DTMF via INFO. It is about to send a
mid-call event that the job of the media server is over (and hence the
controller can send BYE).

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

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

---

From: "Bob Penfield" <[email-masked]>
Date: Tue, 14 May 2002 19:14:26 -0400

----- Original Message -----
From: "Roy, Radhika R, ALASO" <[email-masked]>

> controller can send BYE).

Sounds like a job for the call events package with SUBSCRIBE/NOTIFY. I
strongly agree that INFO is not the right way to do it. Besides, INFO is not
allowed to affect call state.

cheers,
(-:bob

---

From: "Bert Culpepper" <[email-masked]>
Date: Wed, 15 May 2002 10:29:15 -0400

comment below...

> allowed to affect call state.

I don't understand this last sentence, it's not the INFO that affects call
state, the INFO just conveys information.  It's the actions taken by the
3pcc controller based on the information that affects call state.

Regardless...Why complicate the interface between the 3pcc controller and
media server with HTTP and/or SUB/NOT?  The media server is a SIP UA, it can
just send a BYE when its done.  The direction of (11) and (12) just needs to
be reversed IMHO.

Regards,
Bert

---

From: "Eric Burger" <[email-masked]>
Date: Thu, 16 May 2002 07:16:23 -0400

My $0.02:

1. From RFC2976:
     The intent of the INFO method is to allow for the carrying
     of session related control information that is generated
     during a session.

That tells me that a media server telling an application server that
something's happened is very much in scope.

2. There are many, many implementations using the INFO method for just this
purpose.  I offer "working code" as a counter argument to ignoring it.

3. Again, from RFC2796:
     The purpose of the INFO message is to carry application level
     information along the SIP signaling path.

     The INFO method is not used to change the state of SIP calls, or the
     parameters of the sessions SIP initiates.  It merely sends optional
     application layer information, generally related to the session.

Many implementations that use the INFO method, particularly between an
application server and a media server, use it as an inter-application
signaling method.  For example, an application server can use an INFO
message to direct a media server to play a prompt or invoke a script.
SUBSCRIBE is not a correct answer (covered in another e-mail).  Re-INVITE is
a possibility, but is (a) way too heavy and (b) the interaction neither
changes the *session* nor change the state of the session.  INFO is correct
in that the interaction is *about* the session.

4. Saying every interaction is a complete SIP session is impractical from a
performance perspective.  Humans won't wait 50ms - 300ms (depending on your
SIP stack) between utterances within what they perceive to be a single
session.  I can show you lots of non-working code for this one :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Bert Culpepper
Sent: Wednesday, May 15, 2002 10:29 AM
To: 'Bob Penfield'; 'Roy, Radhika R, ALASO'
Cc: 'Sipping (E-mail)'
Subject: RE: [Sipping] WGLC closed, requesting IETF LC on
draft-ietf-sipping-3pcc-00.txt

comment below...

Regards,
Bert

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 16 May 2002 10:14:49 -0400

> something's happened is very much in scope.

To be honest, I really regret that we ever published INFO as an RFC. It
has become the repository for people to do all kinds of non-standard,
non-interoperable stuff and call it "standards based". I have proposed
that RFC 2976 be revved to tighten its usage scenarios, and I feel even
more strongly now based on this discussion. In fact, I would go so far
as to propose that INFO be limited to ONLY carry PSTN signaling as in
the current SIP-T usage. If you want to do anything else, we need to
look at the specific problem and define the appropriate mechanism for
it.

> purpose.  I offer "working code" as a counter argument to ignoring it.

I must have missed the draft which has proposed the INFO method usage
for control of media servers. Oh, wait, its INFO - its already an RFC,
no more spec work required! Silly me.

> in that the interaction is *about* the session.

UPDATE is about "the session" too. I suppose your proposal is we just
discard the UPDATE draft, since INFO already solves our problem? 

> session.  I can show you lots of non-working code for this one :-)

I am not sure what aspect of the draft you are referring to here.

In any case, the 3pcc draft is not about debating the uses of INFO. I
don't want to hold up that draft on this point. So, I will modify the
flow and text to discuss neither.

-Jonathan R.