Advanced SIP Services

Rules:

Outbound call services

Informal service description:
This type of service allows efficient use of human tele-marketing resources by having an auto dialer A dial numbers until an answer is received. Once the auto-dialer gets what it believes is a live answer from a customer C it gives the call to a waiting tele-marketer T.
SIP implementation
Transfer approach:

This is essentially a call-transfer based approach. If billing is somehow based on who sends an INVITE, then the customer gets billed.

  1. The auto-dialer sends a SIP INVITE(C,c1,A,A) to the customer;
  2. The customer C accepts the call, sends a 200 OK to the auto-dialer;
  3. The auto-dialer determines an available tele-marketer, but does NOT send an INVITE to him.
  4. The auto-dialer responds to customer not with ACK but with a BYE(T), and Location field set to the tele-marketer.
  5. Customer then sends a SIP invite to the tele-marketer, tele-marketer responds with 200 OK.

Change existing:
This has the auto-dialer back out without actually sending a BYE. Here, the INVITEs are all sent by the auto-dialer. No data packets should ever get routed to the autodialer. This only works if we allow SDP in an ACK method. The client doesn't open a voice channel until it receives an ACK, so the auto-dialer can't distinguish humans from answering machines or faxes.
sender destination message call-id From SDP
A C INVITE c1 A A
C A 200 c1 C C
A T INVITE c2 C C
T A 200 c2 C T
A T ACK c2 C
A C ACK c1 A T

Change existing call:
The current definition of INVITE allows subsequent INVITEs to the same call-id, which can change any parameter, including the destination address. (This is how the transition from two-party to N-party-with-multicast might work.) The callee is supposed to accept this silently unless it's a major change (such as a new media type), without any user interaction. According to the rules above, the service
sender destination message call-id From SDP remarks
A C INVITE c1 A A
C A 200 c1 C C
A C ACK c1 A - (listen for voice)
A T INVITE c1 A C
T A 200 c1 T T
A T ACK c1 A -
A C INVITE c1 A T
C A 200 c1 A T
A C ACK c1 A T
T C BYE c1 A T telemarketer hangs up
T A BYE c1 A T notifies A

Camp-On

Informal service description:
This is the service that allows a caller to request a call-back from the network when a terminating party's line becomes available. When a caller encounters a busy termination, they can press special digits requesting that the network watch that terminating line, or continually re-check availability of the terminating line. When the network detects an available termination the network calls the originator and then rings the terminator. The SIP specification mentions the ability for the called party to respond to an invite request with a suggested time to call back. But, how would you perform this camp-on type function to allow the caller to contact the called party as soon as they become available, regardless of what their scheduling function predicted? One option would be to support this in the terminating client, by recording the incoming invite message and allowing the called party to call back to the caller when they have finished their previous connection. But, I don't think this is the same type of service since the called party may not be able to distinguish between a caller that wants an immediate call back versus a caller that will try back later. Also, the burden on making the call is placed upon the called party which they may or may not decide to return. It may also have billing implications.
SIP implementation
One problem here is that in an Internet context, the definition of "becoming available" is a bit fuzzier, since parties can easily have multiple call presences, for example, if one call presence just monitors a baby (or the au pair :-)) at home.
  1. The SIP caller can either poll "in the background" with INVITEs.
  2. Delegate this task to a server, with third-party call control as above.
  3. The SIP INVITE contains a (new) Reach option, "Camp-on". If busy, the callee returns a status code 181, "Busy with camp-on" and queues the request. Once the callee finishes the current call, the callee's SIP daemon rings the next pending call and returns a 200 OK response if accepted. The caller can send a BYE request to terminate any pending calls.

Attended call transfer

Informal service description:
A caller dials a number and gets connected to a terminating party. After a conversation with that terminating party, the caller must be transferred to a third party. During the tutorial you suggested that the original terminating party re-direct the caller to the new termination with the "location" capability. But, what happens in the case that the call cannot be completed to the termination? This call failure may occur for any number of reasons (termination busy, no network resources, termination rejects the call, etc.). In the event that the transfer fails, the original terminating party would like to implement alternate handling for the call. How can the SIP protocol, support an attended call transfer allowing the original terminating party to retain control of the call until it has been transferred to their satisfaction? This is a very key capability since it is necessary to perform a large number of services that are available today (operator services, call center, Centrex, call parking/queuing, etc.)
SIP implementation
Similar to the telemarketer solution.

Create call (CS-2 capability)

Informal service description:
The ITU has defined a capability in the CS-2 call model that allows a third party to request that the network establish a call between two points. Since this is a new capability that is still being built into commercially available SCPs it is not known how it will be used to deliver services. But, it could be used to do things like establish scheduled connections for conferencing, batch data sharing, etc. The difficulty with the SIP protocol in providing this type of capability is that the two parties that will be involved in the call may not have any knowledge that they will be participating in a call. In SIP terms, they both receive an invite message to the same call, and the network (or a third party) is sending the invite. But the third part is never connected into the call.
SIP implementation
  1. third party C invites user A, From field is user B;
  2. User A responds with OK and its media capabilities/ports to C;
  3. third party invites user B, putting media capabilities/ports from user A's 200 OK into the INVITE SDP;
  4. user B responds with OK and its media capabilities/ports to C;
  5. third party sends ACK to user A, now including SDP indicating media; capabilities/ports of user B, obtained from user B's OK
  6. third party sends ACK to user B.
As before, C issuing a second INVITE with the joint capabilities would work as well.

Billing

?What are we billing for? Reservations? Gateway services?

The SIP server will know the originator, receiver and time of generation. The network equipment will know the IP addresses and time of usage for the network reservation. You can correlate them based on time and addresses. If that's too hard, just shove the problem into RSVP. PATH and RESV messages can contain opaque user data (policy data blocks), like the Call-ID from SIP.

Also: If the call traverses a proxy server (say, call to customer@mci.com), the gateway can issue a token (something like scrip) to the caller, which is then included in the RSVP request.

Billing for gateway services would use normal SIP (proxy) authentication, with "indication of charges incurred" in the BYE response, for example. This also includes the case where instead of RSVP, a special network for IP telephony is employed.


Last modified: 1997-11-05 by Henning Schulzrinne