Monday, February 18, 2019

读书笔记 - Building Telephony Systems with OpenSIPS (2nd Edition)

这是一本介绍OpenSIPS的书,有14章,感觉全部读完,就可以用OpenSIPS搞一个PBX出来了,但现实架构设计中,我们不仅仅用OpenSIPS, 还会考虑用SBC和Freeswitch来搭建一个PBX系统。基于这个想法,我就只看前2章了,后面的章节如下
Chapter 3: Installing OpenSIPS
Chapter 4: OpenSIPS Language and Routing Concepts
Chapter 5: Subscriber Management
Chapter 6: OpenSIPS Control Panel
Chapter 7: Dialplan and Routing
Chapter 8: Managing Dialogs
Chapter 9: Accounting
Chapter 10: SIP NAT Traversal
Chapter 11: Implementing SIP Services
Chapter 12: Monitoring Tools
Chapter 13: OpenSIPS Security
Chapter 14: Advanced Topics with OpenSIPS 2.1


Chapter 1: Introduction to SIP

RFC 3261 describes SIP version 2. SIP is an application layer protocol used to establish, modify, and terminate sessions or multimedia calls. These sessions can be audio, video, chatting or screen sharing sessions. It is similar to HTTP.

RFC 3665 defines best practices to implement a minimum set of functionalities for a SIP IP communications network. SIP registrar server accepts REGISTER requests and saves the information received in these packets on the location server for their managed domains.

Types of SIP Servers
  • The proxy server: all SIP signaling goes through the SIP proxy, but the RTP packets will go directly from one endpoint to another even if the server is working as a SIP proxy.
  • The redirect server: In this mode, the SIP server is very scalable because it doesn't keep the state of the transactions. Just after the initial INVITE, it replies to UAC with a 302 and is removed from the SIP dialog. Use this mode if you don't need to bill the calls.
  • The B2BUA server: Back-to-Back User Agent server is normally applied to hide the topology of the network and support buggy clients unable to route SIP requests correctly based on record routing. Freeswitch, Asterisk, Yate and otehrs work as B2BUAs. (two legs)
SIP request messages (methods)

Registers the user and updates the location table
RFC 3261
Session establishment
RFC 3261
Acknowledges an INVITE
RFC 3261
Terminates an existing session
RFC 3261
Cancels a pending registration
RFC 3261
Acknowledges a provisional response
RFC 3262
Provides mid-call signaling info
RFC 2976
Instant message transport
RFC 3428
Sends information after subscribing
RFC 3265
Establishes a session to receive future updates
RFC 3265
Uploads the status info to the server
RFC 3903
Asks another UA to act on URI
RFC 3515
Updates a session state info
RFC 3311

Most of the time, we will use REGISTER, INVITE, ACK, BYE, and CANCEL.
INFO is used for DTMF relay and mid-call signaling information.
PUBLISH, NOTIFY, and SUBSCRIBE give support to the presence systems.
REFER is used for call transfer.
MESSAGE is used for chat application.

SIP dialog flow
INVITE, 100 Trying, 180 Ringing, 200 OK, ACK, BYE

A call made using sips: (secure SIP) will use a secure transport, TLS (Transport Layer Security), between the caller and callee. Session details such as the media type and codec are not described in SIP. Instead, it uses the SDP (Session Description Protocol). This SDP message is carried by the SIP message, similar to email attachment.

A combination of the To, From, and Call-ID tags fully defines an end-to-end SIP relation known as a SIP dialog.

While the Via header field tells the other elements where to send a response, the Contact header tells the other elements where to send future requests.

SIP three-way handshake is: INVITE/200 OK/ACK
During the session, the parties can change session characteristics issuing a new INVITE request. This is called reinvite.

SIP transactions and dialogs
According to RFC 3261, a dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. A dialog is a succession of transactions that control the creation, existence, and termination of the dialog. All dialogs do have a transaction (INVITE) to create them, and may (or may not) have a transaction to change them. And the end-dialog transaction may be missing.

The configuration of the SRV records is often used to provide failovers and load sharing between the SIP servers. It is one of the easiest ways to get geographical redundancy in a SIP project.

SIP services
RFC 5359 defines a standard way to accomplish SIP services, including
  • Call Hold
  • Consulation Hold
  • Music on Hold
  • Transfer - Unattended (blind)
  • Transfer - Attended (warm) 
  • Call Forwarding
  • 3-way conference
  • Find-me
  • Incoming Call Screening
  • Outgoing Call Screening 
  • Call Park
  • Call Pickup
  • Automatic Redial
  • Click to Dial
The RTP Protocol
The Real-time Protocol (RTP) is defined in RFC 3550 for the real-time audio and video etc data transporting. It uses UDP as the transport protocol. To be transported, the audio or video data has to be packetized using a codec.

When to use
64 kbps
Use it for toll quality and broad support from gateways
8 kbps
Use it to save bandwidth and keep toll quality
64 kbps
Use it for HD voice
6-501 kbps
OPUS is the most sophisticated codec ever created. It spans from a narrow band audio to HD voice.

The µ-law and A-law algorithms encode 14-bit and 13-bit signed linear PCM samples (respectively) to logarithmic 8-bit samples. Thus, the G.711 encoder will create a 64 kbit/s bitstream for a signal sampled at 8 kHz.

There are 3 ways to carry DTMF in VoIP networks:
  1. inband as audio tones
  2. named events on RTP (RFC 2833)
  3. signaling using SIP INFO messages 
The SIP and OSI model

UDP/TCP/TLS/RTP/SRTP/RTCP/SCTP (Stream control transmission protocol)

To communicate to the PSTN, a PSTN gateway is usually required, except when you have a SIP trunk. The SIP proxy never handles the media. Services such as IVR, voicemail, conference, or anything related to media should be implemented in a media sever. There are many SIP servers fitting this purpose like Asterisk, FreeSwitch, Yate, SEMS from IPTEL, and SilkServer for AG projects.

No comments:

Post a Comment