Subject: Within-Call Signalling and SIP

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 3 Feb 1999 16:14:52 -0500

In the telephony world, a lot of signalling events occur autonomously,
rather than as part of an established sequence.  As a specific example, if
the called party puts the caller on hold and wants that to mean temporary
freeing of network resources between them, the called party needs the
caller's help.  In the telephony world, messages such as Q.931's FACILITY
message can be used to carry the necessary signalling.

I've read draft-ietf-mmusic-sip-cc-00, which doesn't really show any details
of how network resources would be freed up (in the paragraph on Consultation
calling).  Is the following a valid solution?
  -- Caller A establishes a call to B
  -- B wants to put A on hold
     -- B sends an INVITE to A with the same Call-Id as the one with 
        which the call was originally established
     -- B's INVITE specifies no media flow
  -- to retrieve the call B sends another INVITE restoring the original
media flows.

Alternatively, should we be thinking about adding a new in-call request to
SIP's repertoire? 

Tom Taylor
E-mail: [email-masked]  (internally Tom-PT Taylor)
Tel.: +1 613 765 4167     (internally 395-4167)
FAX: +1 613 763 7236     (internally 393-7236)

---

From: Christian Huitema <[email-masked]>
Date: Wed, 3 Feb 1999 17:57:50 -0500 (EST)

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

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 3 Feb 1999 18:58:15 -0600

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,
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Feb 1999 20:31:33 -0500

> signalling.  Eric Zimmerer of Level3 proposed adding such a message

There is probably a need for a few "in-call" methods and no need to
overload a single request with a bunch of functions (as in FACILITY).
Proxies and redirect servers generally can just handle new requests as
before, so there is no penalty in creating specific requests. Things one
might want:

- status request (as in the Level3 example)
- transparent data transport (for signaling)
- possibly liveness tests (being discussed)
- determine capabilities of other side (have that: OPTIONS)

We already have one request to do in-call changes, namely (re)INVITE.
This can indeed serve the purpose of putting a call on hold, as spelled
out in SDP section of the SIP spec. Thus, changes for a call itself
don't need new requests.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 03 Feb 1999 23:47:37 -0500

> message can be used to carry the necessary signalling.

I think the question of "how to handle mid-call events" depends quite a
lot on the particular event. I'm not sure I would rush into a generic do
it all method for this.

>   -- to retrieve the call B sends another INVITE restoring the original

The sequence is correct. There is no relation to freeing of network
resources here, though, since SIP does not control them. In the case of
rsvp, for example, after A responds to B's re-INVITE, B can tear down
the reservation to A, and re-establish before (or after) re-inviting A
to un-hold. With diffserv I don't really see a need for any explicit
"freeing" of net resources, since this is a packet network after all,
and not sending voice frees the resources by definition.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 04 Feb 1999 00:01:37 -0500

> messaging, state change detection, etc. Very powerful idea.

True, your approach of generally using SUBSCRIBE and NOTIFY does allow
for reuse of methods. However, it moves the "reinvention of specialized
methods" to "reinvention of new, specialized body types" or possibly
headers. Its a question of where one would prefer the "newness". I'm
inclined to agree that in bodies is better than in new methods, but
remember that one way or another some new information needs be sent.

> sent as NOTIFIES with body of application/isup or what-have-you.

We need to be more specific here; what in call events are we talking
about? Many of the ISUP messages seem mappable into existing ones.
SUS/RES seem doable with re-INVITES, INR/INF with OPTIONS, for example.

-Jonathan R.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 19 Apr 1999 20:06:37 -0400

What a lot of PSTN interworking problems would be solved if SIP assumed a
reliable transport end-to-end and we could count on "100 Trying" to carry
back the ACM and the "180 Ringing" to carry back the SDP to trigger ringing!

> From:	[email-masked] [SMTP:[email-masked]]
> Sent:	Monday, April 19, 1999 4:48 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: Behavior of SIP Callee user agent
> 
> > Well, never mind.  I found reference that the user agent SHOULD respond
> >with a 1xx as soon as possible if it can't give a final response within
> >200 ms.  This begs the question of what message(s) should map back to
> >an ACM on ISUP.  
> 
> But you probably don't want the call to fall down in the case that it
> doesn't. This is a tricky issue. As I understand it, the ACM is meant
> to indicate that a full set of digits has been entered; this is 
> different from the purpose of the 1xx messages. You may want to consider
> sending back an ACM as soon as your gateway has determined that a complete
> number has been sent. This has some complicated implications for gateways
> which have to support overlapped dialing (unless you just perform a
> simple timeout) -- but I'm digressing too far into implementation issues.
> 
> My point is that, since they mean different things, you probably shouldn't
> wait for a 1xx to send an ACM.  By doing so, you gain nothing and risk 
> interoperability problems.
> 
> > That brings up the issue of what a PSTN originator will hear.  If
> >a 100 Trying maps to an ACM, it would seem the originator would hear
> >dead air unless some requirements were defined for gateways to send
> >ringback when 100 Trying was received and mapped to an ACM.
> 
> And, even then, you may leave the caller in the unexpected situation
> where he hears a few ring tones, followed by a busy signal (in the
> situation where the 100 is followed by a 486 or 600). It may be better
> to, as Arjun suggests, send some sort of call progressing tone until
> you get an actual 180 or final response.
> 
> --
> Adam Roach                 |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS
> L-04
> Ericsson Inc.              | Fax: +1 972 669 0154 | Richardson, TX 75081
> [email-masked]    |                  <*> | USA

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Apr 1999 22:39:42 -0400

> back the ACM and the "180 Ringing" to carry back the SDP to trigger ringing!

There are really two separate problems, and both are solvable:

1. 1XX responses are not reliable
2. 1XX responses are not mandatory

The first of these is solved by an extension Henning and I submitted two
IETF's back, which provides reliable provisional responses. As with
other SIP extensions, the caller (an originating gateway here), would
indicate its need for this extension in a Require header. 

The second problem is addressed in a similar way. We simply define an
extension, say:

org.ietf.send180

and include this in a Require header in the INVITE as well. This
extension, which must always be used with reliable responses, simply
says that you should send a 180 (or 183, as discussed, for remote
generated tones an announcements) when ringback is being provided at the
remote end. Then, the calling gateway sends an ACM when it receives
either 180 or 183.

Of course, as has been pointed out, there are other, harder problems. If
the 180 causes local ringback at the originating gateway, and is then
followed by a 600, this causes the caller to hear a transition from
ringing to fast busy. I don't see any solution to this, however. 

-Jonathan R.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 20 Apr 1999 09:49:25 -0400 (EDT)

On Apr 19,  8:06pm, Tom-PT Taylor wrote:
> Subject: RE: Behavior of SIP Callee user agent

Tom,

The problem is not so much the absence of an end-to-end transport as the
absence of a formal acknowledgement for each step in the calling process.
UDP based protocols do work well if each "command" is immediately
"acknowledged."  In SIP, the INVITE is acknowledged (through either a
provisional response of a definitive response), the definitive response is
acknowledged (through the ACK response to 200), but intermediate responses
are orphans that float in thin air.

The ACM is logically tied to the "ringing" message.  It cannot be issued
after a mere progress without breaking the SS7 semantic -- for example,
without foregoing overlap numbering.  Sending an arbitrary ACM is just
wrong.

One possibility would be to recognized that the ACK can be used in
response to provisional responses (provisional ACK), as a way to
synchronize the sender's and receiver's state machine.

-- 
Christian Huitema
------------------------------
Please note my new address: [email-masked]
http://www.telcordia.com/

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 20 Apr 1999 09:02:18 -0500

Obviously one would return "484 Address Incomplete" rather than "100 Trying"
in the case of overlap dialling, and would not return the ACM until the
requisite SAM in the forward direction justified it.

> From:	Christian Huitema [SMTP:[email-masked]]
> Sent:	Tuesday, April 20, 1999 9:49 AM
> To:	Taylor, Tom-PT [CAR:5V00-I:EXCH]; [email-masked]
	[[TomT]]  ... 
> without foregoing overlap numbering.  Sending an arbitrary ACM is just
	[[TomT]]  ... --

---

From: Christian Huitema <[email-masked]>
Date: Tue, 20 Apr 1999 10:57:14 -0400 (EDT)

> requisite SAM in the forward direction justified it.

Except when dealing with relays.  It may well be that only the final step
in the signalling chain knows that the address is incomplete.  The
intermediate SIP servers could well send a Trying response...