Call Hold

Alice calls Bob, then Bob places the call on hold. Bob then takes the call off hold, then Alice hangs up the call.

Note that hold is unidirectional in nature.However, a UA that places the other party on hold will generally also stop sending media, resulting in no media exchange between the UAs.

Older UAs may set the connection address to 0.0.0.0 when initiating hold. this behavior has been deprecated in favor or using the a=inactive SDP attribute if no media is sent, or the a=sendonly attribute if media is still sent.

Bob may include rendering feature tag in RE-INVITE (contact header) while initiating hold to indicate that Bob's UA is no longer rendering media to Bob.
Contact: <sips:[email protected]>;+sip.rendering="no"

Consultation Hold

Alice calls Bob. Bob places call on hold. Bob calls Carol. Bob then disconnects with Carol, then takes the call with Alice off hold. The call ends when Alice hangs up.

Music on Hold

In this flow,
1. Alice calls Bob
2. Bob answers call
3. Bob places Alice on hold with music.

This is performed by Bob sending a REFER to a Music Server that sends an INVITE with Replaces to Alice. The Music Server then sends RTP music to Alice. Bob picks the call up from hold by sending an INVITE with Replaces to Alice.

Transfer - Unattended

In this scenario
1. Bob calls Alice.
2. Alice then transfers Bob to Carol
4. Alice disconnects with Bob.
5. Bob establishes the session to Carol then reports the success back to Alice in the NOTIFY.

Note: If the transfer fails, Bob can send a new INVITE back to Alice to re-establish the session.

Transfer - Attended

In this scenario
1. Alice calls Bob.
2. Bob puts Alice on hold
3. Bob calls Carol to announce transfer
4. Bob places Carol on hold.
5. Bob transfers Alice to Carol, which replaces the session between Bob and Carol.
6. Carol then disconnects session with Bob.
7. Alice reports success of transfer to Bob, who then disconnects with Alice.

In this example, the Replaces header field [RFC3891] is inserted into the Refer-To URI by Bob. Note that the Refer-To URI is the Contact URI returned by Carol in the 200 OK response [10]. This ensures that only the correct instance of Carol is reached.

Transfer - Instant Messaging

In this scenario,
1. Alice and Bob establish a session between them.
2. Bob wants Carol to take the call and so sends an Instant Message (IM) to Carol containing Alice's URI and an embedded Replaces header field.
3. If Carol clicks on the URI, Carol's SIP UA sends an INVITE to Alice, which replaces the session with Bob.

This scenario shows the use of the SIP MESSAGE [RFC3428] method to pass the URI. However, another IM protocol or other method could have been used to pass the URI from Bob to Carol.

Call Forwarding Unconditional

In this scenario,
1. Bob has set call forward.
2. Alice calls Bob. The proxy server rewrites the Request URI, and forwards the INVITE to a Gateway.

Note: Forwarding could be accomplished using a redirect (302 Moved Temporarily response).

Call Forwarding - Busy

In this scenario,
1. Bob wants calls to B1 forwarded to B2 if B1 is busy (this information is known to the proxy).
2. Alice calls B1, B1 is busy, the proxy server places call to B2.

Call Forwarding - No Answer

In this scenario,
1. Bob wants calls to B1 forwarded to B2 if B1 is not answered (information is known to the proxy server).
2. Alice calls B1 and no one answers.
3. The proxy server then places the call to B2.

3-Way Conference - Third Party Is Added

In this scenario,
1. Alice and Bob are in a 2-party call (session) when
2. Bob wishes to add Carol into the conversation. Bob is capable of media mixing in a 3-party call.
3. Bob first sends a re-INVITE to Alice, changing Contact URIs to one that indicates Bob's mixer and acts like a focus. As a result, Bob includes the "isfocus" feature tag [RFC3840] as described in [RFC4579].
4. Bob then INVITEs Carol using the same Contact URI.

Note that Bob could wait to re-INVITE Alice until after Carol has answered. Bob could also put Alice on hold before calling Carol.

3-Way Conference - Third Party Joins

In this scenario,
1. Alice and Bob are in a 2-party call.
2. Carol wishes to join, resulting in a 3-party call.
Carol could have learned Bob's dialog identifier using some non-SIP means, or possibly from a NOTIFY with the dialog package sent by Bob.
3. Carol sends an INVITE to Bob containing a Join header identifying the dialog between Alice and Bob.
4. Bob re-INVITEs Alice to switch to focus mode and includes the "isfocus" feature tag [RFC3840] as described in [RFC4579].
5. Bob then accepts the INVITE from Carol, resulting in the 3-way call.

Find-Me

In this scenario,
Alice's call to Bob will result in an attempt to locate Bob by calling locations from a list of contacts.
The location to answer the call becomes the active set; no other sets may join the call.

While this flow shows a sequential search, the search could be accomplished using parallel forking.

Call Management (Incoming Call Screening)

In this scenario,
1. Bob has an incoming call screening list; Alice is included on the list of addresses from which Bob will not accept calls.
2. Alice attempts to call Bob.
3. Bob does not accept INVITEs that have not been screened by the proxy.
4. Alice retries the call through the proxy.
5. Proxy 1 challenges Alice for authentication.
6. Alice responds by sending an INVITE with authentication credentials in it.
7. The screening proxy inserts an announcement URI in an Error-Info header field, which Alice accesses by sending an INVITE to listen to the Announcement.

Note that call screening cannot be done using the From header, instead some form of authentication credentials must be used.

The Announcement Server uses the automaton and rendering feature tags contact header of 200 OK to indicate that it is a media server only capable of playing announcements
Contact: <sips:ms.biloxi.example.com>;automaton;+sip.rendering="no"

 

Call Management (Outgoing Call Screening)

In this scenario,
1. Alice has an outgoing call screening list; Bob is included on the list of addresses to which Alice will not be able to place a call.
2. Alice attempts to call Bob.
3. Proxy replies with a 403 screening failure status code.
4. Alice could establish a session to listen to the announcement in the Error-Info header field.

Call Park

In this scenario,
1. Alice calls Bob.
2. Bob then parks the call at the Park Server by sending a REFER to the Park Server.
3. The server sends an INVITE to Alice, which replaces the session between Alice and Bob.
4. The Park Server utilizes the automaton, rendering, and byeless feature tags in [09] INVITE to indicate its capabilities to Alice.
5. The call is accepted by Alice and causes Alice to send a BYE to Bob.
6. Bob receives notification of the successful park, and also receives the dialog identifiers in the application/sip body of the NOTIFY response.
7. Carol wishes to retrieve the call. She obtains the dialog identifiers from a NOTIFY from the Park Server.
8. Carol sends an INVITE containing the dialog identifiers to Alice, which replaces the session with the Park Server.
9. Alice accepts the call and sends a BYE to the Park Server.

Note that this call flow is a special case of call transfer.

Note also that this flow could also be used for Music on Hold.

Call Pickup

In this scenario, Bob and Bill are part of a work group at example.com that can pick up each other's calls.
1. Alice calls Bob, who does not answer.
2. Bill wishes to pick up the call and sends a SUBSCRIBE to Bob to retrieve the dialog information.
3. Bill then generates an INVITE with a Replaces to Alice.
4. Alice answers the INVITE and sends a CANCEL to stop Bob's phone ringing.
Note that the relative order of the 487/ACK sequence [11/12] and the 200 OK to the CANCEL [10] is not deterministic.

This call flow shows the use of the "early-only" parameter [RFC3891] in the Replaces header field of [07]. This parameter prevents Alice from accepting the INVITE if Bob has already accepted the INVITE. If Bill had wished to "take" the call from Bob regardless of whether he had answered, the parameter would not have been present in [07].

Also note that the subscription between Bob and Bill could have been established prior to Alice's call.

Automatic Redial

In this scenario,
1. Bob is initially busy when Alice calls.
2. Alice subscribes to Bob's call state using a SUBSCRIBE [04].
3. Bob sends a NOTIFY [08] when Bob is available.
4. Alice is alerted, then Alice sends an INVITE to Bob to establish the session.
5. The subscription is terminated using SUBSCRIBE [16].

Click to Dial

In this scenario,
1. while browsing the web on his PC, Bob clicks on Carol's SIP URI, intending to establish a session with Carol.
2. Bob's web browser passes the SIP URI to the SIP client on Bob's PC.
3. The PC client is configured with the URI of Bob's SIP phone. A REFER is sent to the SIP phone, which results in the establishment of the session between Bob and Carol.

Note that Bob's PC requests that no REFER dialog be established by the use of the Refer-Sub: false header field [RFC4488].

 

Related Pages

Related Links

Links