Figure 5.19 Call transfer call flow
The following INVITE message establishes a call from the calling party to the transfer agent.
Note that the value from the Refer-To header field of the REFER message has been put into the Request-URI and To header field.
INVITE sip:transfer_agent@195.37.77.101 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.130
From: <sip:caller@iptel.org>;tag=32e189db-ec7e
P.168
[IP Telephony Cookbook] / Setting Up Advanced Services
To: <sip:transfer_agent@195.37.77.101>
Contact: <sip:caller@192.168.0.130>
Call-ID: 205e377f-7042-b00c-0@192.168.0.130
CSeq: 20142 INVITE
Max-Forwards: 70
Content-Type: application/sdp
Content-Length: 258
v=0
o=caller 0 0 IN IP4 192.168.0.130
s=-
c=IN IP4 192.168.0.130
t=0 0
m=audio 5004 RTP/AVP 0 8 4 18 2 15
a=ptime:20
a=rtpmap:0 PCMU/8000
The following BYE message (green in the call flow) terminates the call between calling party and called party.
BYE sip:195.37.77.101:5060;lr SIP/2.0
Via: SIP/2.0/UDP 192.168.2.32:5060
From: <sip:callee@iptel.org>;tag=00036bb90fd3000
To: <sip:caller@iptel.org>;tag=992d8f53-ca7e-c73f
Call-ID: 90bdee69-eb4f-3e1c-9833-499857a5b2b2@192.168.0.130
CSeq: 104 BYE
Content-Length: 0
Route: <sip:caller@193.175.135.38:40012>
-/ 5.2.2.3 Unconditional call forwarding
A user's ability to determine call processing is a great strength of IP Telephony.With SIP in particular, users are able to associate any number of devices with their address of record. SIP
telephones register their whereabouts automatically using the SIP REGISTER request. Users may also introduce additional contacts by means of provisioning. Upon receipt of an incoming call request (INVITE method), a proxy server forwards the request to all registered contacts.
Eventually, all registered phones start ringing in parallel and the conversation begins with the device which the user picks up.
The ability to manipulate contacts allows users to determine handling of incoming calls. For example, a user may wish to decide that all incoming calls will ring his cell phone as well.The following set of examples shows how the manipulation of registered user contacts can be used for forwarding purposes.The examples use SER and its command line control tool, lserctl, to manipulate contacts of a user.Typically, this job is done through a Web interface such as Serweb because it is more convenient.The commands used are ul add USER SIP_CONTACT for introducing a new forwarding address and ul show USER for displaying currently registered contacts.
P.169
[IP Telephony Cookbook] / Setting Up Advanced Services
First, the current status of registered contacts is inspected.The command reveals that a SIP phone registered a contact from IP address 212.202.42.68.
jiri@fox:~$ serctl ul show jiri
<sip:212.202.42.68:55723<;q=0.00;expires=272
To enable forwarding of incoming calls also to cell phone, introduce contact to the PSTN
gateway. If a call arrives, the proxy server will ring both the previously-registered SIP phone and the manually-provisioned cell phone contact.
jiri@fox:~$ serctl ul add jiri sip:123456@iptel.org
sip:123456@iptel.org
200 Added to table
('jiri','sip:123456@iptel.org') to 'location'
jiri@fox:~$ serctl ul show jiri
<sip:123456@iptel.org>;q=1.00;expires=1073741820
<sip:212.202.42.68:55723>;q=0.00;expires=21
-/ 5.2.2.4 Conditional forwarding
Called parties frequently wish to redirect incoming calls to an alternative destination if the primary destination fails to answer.The reasons for failure are multi-fold.They may include a busy called party, disconnected called party's phone, user who currently does not answer or user denying the incoming call.The alternative destination is typically a voicemail system but it may be also another human or some other SIP device.
The following configuration fragment demonstrates how set up such a feature using SER:
# if invitation recipient off-line, forward to voicemail
if (!lookup("location")) {
rewritehostport("voicemail.iptel.org");
t_relay_to_udp("voicemail.iptel.org", "5060"); break;
};
# user on-line, forward INVITE to him; also set up a failure
# handler so that we can redirect to voicemail if the
# call is not established successfully
if (method=="INVITE") {
t_on_failure("1");
};
t_relay();
....
# alas, the call was not established successfully; well,
# let's retry with voicemail then
failure_route[1] {
revert_uri(); # resend to voicemail with original request URI
P.170
[IP Telephony Cookbook] / Setting Up Advanced Services
rewritehostport("voicemail.iptel.org");
append_branch();
t_relay_to_udp("voicemail.iptel.org", "5060");
}
Whereas this example demonstrates a global site policy which is applied to each user, some subscribers may wish to formulate their specific call processing preferences. How the preferences are formulated and provisioned in the SIP server is not necessarily governed by standards. SIP
servers may have their own proprietary user-provisioning interfaces, typically with a Web front-end. On the other hand, a standardised way of call handling allows easier service portability.The IETF standard for describing called party’s preferences is called Call Processing Language, CPL. In short, it is a simple XML-based language that allows subscribers to determine how the server handles calls for them. It is a special-purpose language that supports the specification of most common types of call processing. CPL does not allow script writers to affect the behaviour of the server in a way which could compromise the security of the server.
Whereas it is simple enough, most users will not be willing to write SER scripts. It is envisioned that CPL scripts will be generated and edited by applications with a convenient user interface.
The following picture shows a screen snapshot of iptel.org's CPL editor.
Figure 5.20 CPL editor
-/ 5.3 Multipoint conferencing
Multi-party conversations are known from the PSTN world.The function is often provided by a company's PBX. It is also possible to use a commercial service. A central part of the service is the Multipoint Conference Unit (MCU). In order to use the service, a session leader must make a reservation for the session at the MCU. Every MCU has a different interface to do so. MCUs in the IP Telephony world usually offer a Web-based form for this.
At the time the conference is planned, each user calls the phone number of the MCU. After that, a number must be dialled to denote the session that the user wants to join, because an MCU can support multiple sessions at the same time. A password is required to prevent uninvited parties from joining the conference. Some MCUs can initiate the set up of the conference itself by dialling all the parties. It needs to know everyone's phone number in advance, of course.
P.171
[IP Telephony Cookbook] / Setting Up Advanced Services
The main function of the MCU starts at this point in the conference: it receives the audio signals of every party in the session, mixes the sources and copies the result to everyone except for the source party.This happens in real time, so everyone will hear everyone.This way of conversing has its specific ways of interaction between the parties. If a party wants to speak, it should be clear that the previous party has ended his part of the conversation.When collisions occur, it is useful if the session leader gives the word to one of those who wish to speak.These aspects have been investigated in the social-cultural area, but are not part of this cookbook.
Now that the functionality is known in general, more details on the case of IP Telephony MCUs can be given. An MCU can be obtained either in hardware or in software. Many gatekeepers are equipped with built-in MCU software functionality. In case of a hardware MCU, the main interface is, of course, an Ethernet connection. From a functional point of view, users cannot approach the MCU directly over IP. No matter whether H.323 or SIP are used for setting up regular two-party calls, a user can only dial in to the MCU through a gatekeeper or SIP Proxy.
Parties that use a PSTN phone can also join a conference by means of the IP-to-PSTN gateway.
Figure 5.21. MCU function in gatekeepers
Modern MCUs can support both audio and video.The calling parties must support the audio and video codec that the MCU has on board. Some MCUs have the possibility to transcode between codecs, enabling users with different codecs to join the same conference. If video is also distributed by an MCU, the video streams cannot be mixed. One way this distribution mechanism is implemented is that only the video signal of the source with the loudest audio signal is transmitted to all users at that point of time (this in audio switching mode).There are other options, such as chair-controlled, in which the chair can lock the video (and possibly audio too) on one participant, or presentation mode. One participant is chosen and both audio and video are locked on the presenter; the rest of the audience can only listen. Some MCUs offer a Continuous Presence mode, in which the video signals is displayed in a matrix that shows all users to every user.
Modern MCUs support other layouts as well. An alternative to using an MCU in the IP world is to use IP Multicast. In this case, all parties transmit their audio (and video) over a Multicast channel. All users must tune in to the channels of everyone else.This means that the total amount data traffic increases with every user that joins the conference. Unfortunately, few networks support Multicast.
P.172
[IP Telephony Cookbook] / Setting up Value-added Services
Setting up Value-added Services |-