Advanced SIP Services
Rules:
- INVITE for the same call-id change the existing call, without
requiring user confirmation.
- Calls are not owned by the initiating entity. This eases call
transfer.
- Responses are always sent to the host that sent the request.
- If the BYE came from a host different than the INVITE, also send a
BYE to the host that issued the INVITE.
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.
- The auto-dialer sends a SIP INVITE(C,c1,A,A) to the customer;
- The customer C accepts the call, sends a 200 OK to the auto-dialer;
- The auto-dialer determines an available tele-marketer, but does NOT send
an INVITE to him.
- The auto-dialer responds to customer not with ACK but with a BYE(T),
and Location field set to the tele-marketer.
- 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.
- The SIP caller can either poll "in the background" with INVITEs.
- Delegate this task to a server, with third-party call control as above.
- 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
-
- third party C invites user A, From field is user B;
- User A responds with OK and its media capabilities/ports to C;
- third party invites user B, putting media capabilities/ports from
user A's 200 OK into the INVITE SDP;
- user B responds with OK and its media capabilities/ports to C;
- third party sends ACK to user A, now including SDP indicating media;
capabilities/ports of user B, obtained from user B's OK
- 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