Subject: RE: Within-Call Signaling and SIP

From: "Donovan, Steven R. (MCI)" <[email-masked]>
Date: Thu, 4 Feb 1999 14:34:41 -0000

It doesn't seem right to add the messaging overhead of a SUBSCRIBE for
signaling information that is by its nature end-to-end signaling.  This is
information that should be sent along the signaling path regardless of
explicit expressions of interest in the information.  These within-call
signaling messages should be treated just like all of the other call related
messages.  Just as an egress gateway should not need to subscribe to the BYE
method, it should also not need to subscribe to the INFO/SIGNAL method.

DTMF signaling information could be handled in the same manner.  (Note that
I don't mean DTMF audio information, which clearly needs to be carried as
part of the RTP stream).

Steve

> -----Original Message-----
> From:	Willis, Dean. 
> Sent:	Wednesday, February 03, 1999 6:58 PM
> To:	Christian Huitema; Tom-PT Taylor; [email-masked]
> Subject:	RE: Within-Call Signalling and SIP
> 
> 
> Why do we keep reinventing new specialized methods like PING and INCALL
> and PRESENCE and so on . . . all these functions can be handled by
> simple, reuasable message primitives. It's just a matter of defining the
> message classes, defining message bodies, and describing the
> subscription policy (explicit and implicit) mechanism. . . and it makes
> the core parsers a heck of a lot simpler!
> 
> The proposed subscribe and notify methods, given classful message
> contents, could be used to carry in-call signalling of all sorts --
> DTMF, ISUP Facility, etc. They could also be used to support presence,
> messaging, state change detection, etc. Very powerful idea.
> 
> Let's look at a couple of potential cases:
> 
> 1) In-call ISUP signalling between UAS/UAC gateways: Each gateway
> SUBSCRIBES to class "incall" from other gateway. In-call messages are
> sent as NOTIFIES with body of application/isup or what-have-you.
> 
> 2) Instant messaging: INVITE is used to establish conference with id
> <CALL-ID>. Each user agent SUBSCRIBES to class "message/<CALL-ID>" on
> other participating user agents. Each message is transmitted as NOTIFY
> class "mesage/<CALL-ID>" with text body.
> 
> 3) End-node call state (PING): Proxy sends SUBSCRIBE class
> "state/<CALL-ID>" (equivalent to PING request), agent replies (PING
> response) NOTIFY class "state/<CALL-ID>" with state of call <CALL-ID> in
> body.
> 
> 4) End-node reachability state (time mark): Proxy sends SUBSCRIBE class
> "mark/<PERIOD>" to receive a NOTIFY class "mark" each <PERIOD> seconds.
> 
> 5) In-call DTMF signalling, useful for signalling-only (non-media) value
> added service processors, such as supplementary account code loggers:
> Service node SUBSCRIBES to class "dtmf/<CALL-ID>" or implicit subscribe
> is assumed. User agent (gateway, etc). sends NOTIFY class
> "DTMF/<CALL-ID>.
> 
> and so on . . .
> 
> The alternative is to change the spec and add a method every time we
> need a new message class, argue about reliability for the method, etc.
> 
> --
> Dean Willis
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of
> > Christian Huitema
> > Sent: Wednesday, February 03, 1999 4:58 PM
> > To: Tom-PT Taylor; [email-masked]
> > Subject: Re: Within-Call Signalling and SIP
> >
> >
> > Tom,
> >
> > I concur.  We could in fact use a generic "in call" command
> > (and response)
> > for facilities, and also for information requests.  This is even more
> > needed for inetrworking with ISUP than for Q.931, if only to carry
> > signalling.  Eric Zimmerer of Level3 proposed adding such a message
> > in his draft.
> >
> > --
> > Christian Huitema
> >