ip telecom signaling: softswitch, h.323, and sip with sdp
TRANSCRIPT
Chiang, Wei-Kuo (江為國)
Associate Professor Department of CSIE National Chung Cheng University Office : EA 311 Phone : 05-2720411~33126 Email : [email protected]
URL : http://www.cs.ccu.edu.tw/~wkchiang/
IP Telecom Signaling:
Softswitch, H.323, and SIP with SDP
Outline
Introduction What is SIP? Why SIP?
When SIP? Where SIP?
SIP Protocol SIP Basics
SIP Message
SIP Communication
SIP Extensions
SIP in NGN 3GPP IP Multimedia Subsystem (IMS)
IMS Call Session Control Function (CSCF)SIP Protocol原理 2
The Telephone Network (1/2)
SIP Protocol原理 3
Class 5
End Office Switch
Circuit Switched Network
Intelligent
Peripheral
Signal
Transfer
Point
Service
Control
Point
Class 4
Tandem Switch
Service
Data
Point
+
Transport Layer
Control Layer
SS7 Signaling
ISUP Messages
INAP/TCAP Messages
備忘稿
傳統電信網路中電話建立的過程為:語音(Voice)部份是經由局用交換機(CO Switches)之間的Trunk介面傳輸;信令(Signaling)部份則是透過SS7網路傳遞。
如果只是一般的通話,負責通話控制(Call Control)的SS7 ISUP信令,僅會透過SS7網路的信號轉運點(Signal Transfer Point;STP),在發話端交換機(Originating Switch)與受話端交換機(Terminating Switch)之間傳送;
然而,當通話需要智慧型網路服務(IN Services)時,則要發送SS7 TCAP信令,經由SS7網路轉送至提供該服務的服務控制點(Service Control Point;SCP),要求提供該項服務;
若是該項服務包括語音播放(Announcement) 、互動語音回應(Interactive Voice Response;IVR),此時SCP就會要求智慧型設備(Intelligent Peripheral;IP)播放語音給發話端,同時偵測發話端的按鍵,並將按鍵結果之DTMF回傳給SCP,用來決定該項服務的進行。
SIP Protocol原理 4
The Telephone Network (2/2)
5 Basic Components in Intelligent Networks SSP/Service Switching Point
switching, signaling, routing, service invocation
STP/Service Transfer Point
signaling, routing
SCP/Service Control Point
service logic execution
SDP/Service Data Point
subscriber data storage, access
IP/Intelligent Peripheral
resources such as customized voice announcement, voice recognition, DTMF digit collection
SIP Protocol原理 5
SSP
SCP SDP
STPIP
SSP
STP
TCAP messages
ISUP messages
Voice
Telephony Switches
Hierarchy of telephony exchanges (switches)
Class 1 – Regional
Class 2 – Sectional
Class 3 – Primary
Class 4 – Toll
Class 5 – Central OfficeAll telephony lines terminated in a central office
The central office (CO) offered only local services
Classes 1~4 switch connections only, have no subscribers attached to them
The lower the class number and the bigger the exchange
SIP Protocol原理 6
ISUP Signaling
Used as the protocol for setting up and tearing down phone calls between switches
Initial Address Message (IAM) To initiate a call between two switches
Address Complete Message (ACM) To indicate that the call party’status
Answer Message (ANM) To indicate that a call has been accepted by the called party
Release Message (REL) To initiate call disconnection
Release Complete Message (RLC)
SIP Protocol原理 7
ISUP Call Establishment
SIP Protocol原理 8
Calling
IAMSetup
Originating
SSP
ACMAlerting
ANMConnect
Tandem
SwitchCalled
IAM SetupIAM
Terminating
SSP
AlertingACMACM
ConnectANMANM
Tandem
Switch
Conversation
ISUP Call Release
SIP Protocol原理 9
Calling
REL
Disconnect
Originating
SSP
RLC
Release
Tandem
SwitchCalled
REL
Disconnect
REL
Terminating
SSP
RLC
RLC
Release
Tandem
Switch
備忘稿 建立通話,發話端的交換機會送出 IAM。IAM 帶有發話人電話號碼、收話人電話號碼、傳輸的輸求、發話人種類(一般通話、系統商通話、付費電費)等資訊。
經由 STP 傳輸到收話端的交換機後,會回傳一個 ACM 來告知發話端:「通話已經連接到了目的地。」而 ACM 會開啟一個由收話端到發話端的單向音訊路徑,如果收話端可以接聽的話,發話端即可聽到撥話時的振鈴聲(ring-back tone)。如果不可以接聽的話,發話端即可聽到撥話時的嘟嘟聲(busy tone)。
嚴格來說,ACM是一個 optional 的訊息,如果不回傳 ACM 就不會開啟單向音訊路徑,並不會影響到通話建立的成功率,而發話端必須等到完整的通話建立之後才會知道通話已經建立。但是當撥話之後,如果發話端能先聽到 ring-back tone 就好像收話端可以即時的 response (雖然尚未完全建立通話),因此大多數仍然會回傳 ACM。
收話端接起電話時,收話端的交換機會回傳一個 ANM,而這個訊息有兩個功能:開啟雙向的音訊路徑以及開始對通話計費。
通話結束之後,當兩端有使用者掛下電話時,該方交換機會送出 REL 訊息,另一方的交換機收到後則會送出 RLC 的訊息。在 RLC 回傳到對方的交換機之後,通話便結束了。
SIP Protocol原理 10
What is SIP?
SIP (Session Initiation Protocol)
Application-Layer Control Signaling Protocol
SIP is Text-based, HTTP-like, “Request-Response”
establish, modify and terminate multimedia sessions
SIP (+ SDP) to describe the session characteristics
SIP Protocol原理 11
SIP Signaling
IP Network
RTP Media Stream
SIP User SIP User
Related Specifications
SIP: Session Initiation Protocol
J. Rosenberg , H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
RFC 2543(-> 3261prop), March 1999 (-> June 2002).
SDP: Session Description Protocol
M. Handley, V. Jacobson, C. Perkins
RFC 2327(-> 4566prop), April 1998 (-> July 2006).
RTP: A Transport Protocol for Real-Time Applications
H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson
RFC 1889(-> 3550std64), January 1996 (-> July 2003).
SIP Protocol原理 12
SIP History
Developed in SIP Working Group in IETF
Work began 1995
Proposed standard RFC 2543, February 1999
Sep. 1999 split from MMUSIC Multiparty Multimedia Session Control
New Version of SIP - RFC 3261, June 2002
Applied to NGN signaling
SIP for Signaling Transparency inter-softswitch communications
SIP for Softswitch Service Interface
Call control protocol in 3GPP IP Multimedia Subsystem SIP Protocol原理 13
Softswitch Overview
Softswitch: Emulating Circuit Switching in Software
SIP Protocol原理 14
IN/SCP
PSTN
Local Switch
PSTN
Local SwitchSTP SS7 Network
IP Network
RTP Streams
MGC MGC
Trunk
GatewayTrunk
Gateway
SIP-T
SGSG
SIGTRAN
MEGACO
IP Phone
9000 Personalized VoIP
Service System
Application Server
Introduction to Telecom. Networks Voice over IP (Internet Telephony)15
Softswitch Overview (2/2)
Softswitch Provides Open Layered Architecture
• Solutions in a proprietary box
• Expensive
• Little room for innovation
Circuit-Switched
Transport
Hardware
Call Control &
Switching
Services &
Applications
P
R
O
P
R
I
E
T
A
R
Y
• Solutions are open standards-based
• Customers choose best-in-class products
• Open standards enable lower cost for innovation
Soft-Switched
Transport Hardware
Softswitch Call Control
Services, Applications & Features
(Management, Provisioning and
Back Office)
Open Protocols APIs
Open Protocols APIs
Open APIs for 3rd Party App develop.
Best-in-class Access Devices.
Scalable, Open Interfaces for Comm.
Softswitch Architecture
SIP Protocol原理 16
CO
Switch
STP
SCP
CO
Switch
STP
SCP
Signaling Layer
Transport Layer
IP
SIP-T
Media
Server
RTP
SIP-?/
MGCP
SIP-TSI
Media
Gateway
Controller
MGCP/
MEGACO
Phones
App.
Server
Media
Gateway
Controller
SIGTRAN
SSA/SCTP
MGCP/MEGACOTrunking
Gateway
Signaling
(SS7)
Gateway
SS7 TCAP
ISUP/TCAP
17
Softswitch Architecture (2/2)
Media Gateway Controller (MGC) provides basic call control, signaling, manages resources, generates CDR
Application Server (AS) hosts enhanced services:
calling card, 800 translation, voice mail, follow-me
provides service/AP interfaces access to underlying service & switching functions
Media Server (MS) provides specialized resources:
IVR, conferencing, facsimile functions
AS can access MS to utilize resources on MS
SIP Protocol原理
Softswitch Operations
Inter-Softswitch Communications
SIP Protocol原理 18
Local
Switch
STP
Trunking
Gateway
Signaling
(SS7)
Gateway
Media
Gateway
Controller
STP
Trunking
Gateway
STP
Media
Gateway
Controller
Signaling
(SS7)
Gateway
STP STP
Domain A Domain B
Local
Switch
Routing
Directory
3
1
5
2
ISUP IAM
4
SIGTRAN
MGCP/MEGACO
6 SIP-T
7
9
16
Voice
RTP
8
ISUP IAM
12
13
Voice
10
11
14 ISUP ACM
15 ISUP ANM
ISUP ACM
ISUP ANM
19
MGCP/
MEGACO
Phones
Trunking
Gateway
Signaling
Gateway
MGC
SIGTRAN
SSA/SCTP
RTP
MGCP/MEGACO
SS7 TCAP
ISUP/TCAP
Softswitch Protocols (1/3)
Concept of MGCP/MEGACO
CO
Switch
STP
SCP
PSTN
Phones
Media
Gateway
MGC
Connection
Create
Delete
Modify
Event Notification
Request
Status
Query
Response
Success
Failure
Event
Notify
Status
Report
Dumb Client
Stateless
Intelligent
Server
SIP Protocol原理
20
Softswitch Protocols (2/3)
IETF SIGTRAN - for SS7 over IP
ISUPTCAP
SCCP
MAP
MTP
OSI Layers
Application
Presentation
Session
Transport
Network
Data Link
Physical
INAP
SS7 Protocol Stack
ISUPTCAP
SCCP
MAP
SCN Signaling Adaptation
(SSA)
Common Signaling Transport
(CST)
IP
INAP
SIGTRAN Protocol Stack
SIP Protocol原理
21
CO
Switch
PSTN
Phones
Trunking
Gateway
MGCP/MEGACOCO
SwitchTGW
Softswitch Protocols (3/3)
SIP-T (SIP for Telephones) : RFC 3372 (Sept.2002)
interface between softswitches
MGCMGC
STP
SCP
Signaling
Gateway
SIGTRAN
SSA/SCTP
SS7 TCAP
ISUP/TCAP
STP
SCP
SG
SIP-T
SIP Message +
Mid-call control
Header
ISUP
SDP
. . .
ISUP/SS7
Messages
MTP
ISUP
ISUP/IP
Messages
ISUP
IP
SIP
UA
SS Adapt.
SCTP
SIP Protocol原理
IP-PSTN Converged Network
SIP Protocol原理 22
CO
Switch
STP
SCP
CO
Switch
STP
SCP
Trunking
Gateway
Signaling
(SS7)
GatewayMedia
Gateway
Controller
Residential
Gateway
RTP
SS7 TCAP
ISUP/TCAPMGC
SG
TGW
SIP-T
SIP
Phones
SIP
Server
SIP
Server
SIPAS
MS
SIP
Call Flow (1/2)
SIP bridging
SIP Protocol原理 23
PSTN Proxy Softswitch 2Softswitch 1 PSTN
IAM
ACM
ANM
REL
RLC
IAM
ACM
ANM
REL
RLC
INVITE
18x
200 OK
BYE
200 OK
100 TRYING
ACK
Conversation
Call Flow (2/2)
PSTN Origination – IP Termination
SIP Protocol原理 24
PSTN Proxy SIP PhoneSoftswitch
IAM
ACM
ANM
REL
RLC
INVITE
18x
200 OK
BYE
200 OK
100 TRYING
ACK
Conversation
INVITE
18x
200 OK
ACK
BYE
200 OK
H.323 Architecture
SIP Protocol原理 25
Has Been Adopted by Vendors for Years
H.323Terminal
H.323Terminal
H.323MCU
H.323Terminal
H.323Gateway
H.323Gatekeeper
Packet Based Network
Scope of H.323
GSTN/PSTN
H.323 Terminal
SIP Protocol原理 26
H.323 Call Setup Flow
SIP Protocol原理 27
Logical Channel
3. Setup
Q.931 Call Signaling Channel
RAS Channel
1. ARQ (alias address/bandwidth)
2. ACF (call signaling channel address/bandwidth)
5. ARQ 6. ACF
8. Connect (H.245 Address)
4. Call Proceeding
7. Alerting
H.245 Control Channel (Logical Channel 0)
Master/Slave Determination
RTCP StreamRTCP Stream
RTP Stream
Gatekeeper
Terminal
Terminal
Capability Exchange
OpenLogicChannel (RTCP address)
OpenLogicChannelACK (RTP & RTCP address)
H.323 Gateway
SIP Protocol原理 28
H.323 Gateway
System
H.323 Terminal
(NetMeeting)
package
switch
network
H.323 Protocol
PBX
Phone Phone Phone
Internet/
Intranet
H.323 Gateway
System
PBX
Phone Phone Phone
PSTN
(2)
(4)
(5)(1)
Call Route
Table(3)
Why SIP? (1/2)
Evolution Traditional Telecom (SS7) -> IP Telecom (H.323/SIP)
Voice call (H.323/SIP)
Multimedia Session (SIP)
Converged Service (SIP)
A powerful alternative to H.323
More flexible, simpler
Easier to implement advanced features
Better to support of intelligent user devices
Transport independence (UDP, TCP, or SCTP)
SIP Protocol原理 29
Why SIP? (2/2)
It is easier to support than H.323
Lots more products than H.323
Cheaper than H.323
Does more than H.323
Has digest authentication (encrypted shared key for users)
In practice SIP has more features than H.323.
All the Video/PABX Manufacturers are moving to SIP!
Find a H.323 client for Mac or Unix – no, you can not!
But there are SIP clients for Mac, Unix, PDAs, Microsoft messenger is a Video capable SIP client (support G.722.1 and H.263), GPRS, G3, ….!
SIP Protocol原理 30
By Stephen Kingham, 2005
H.323 vs. SIP
SIP Protocol原理 31
IETF ProtocolITU-T Protocol
SIPH.323
RFC 2543 (March 1999)V.1 ( May 1996)
Working Groups: SIP,SIPPING, and SIMPLE
Study Group 16
Now RFC 3261 (2002)Now V.7 (2009)
H.323 vs. SIP
SIP Protocol原理 32
User AgentUser Node
SIPH.323
Registrar, Proxy, Redirect Server
Network Node
None*
IP-PSTN Gateway
Terminal
Gatekeeper
Multipoint Control Unit (MCU)
IP-PSTN Gateway
*What SIP cannot provide?
H.323 vs. SIP
SIP Protocol原理 33
SIPSignaling
SIPH.323
SDPCapacity
Negotiation
AnyCodecs
RTP/RTCPReal-time
Communication
RSA/Q.931
H.245
Any
RTP/RTCP
H.323 vs. SIP
SIP Protocol原理 34
ASCIIMessage Encoding
SIPH.323
UDP and TCPMostly TCP
Transport
NoneData
Conference
DNS, TRIP, ENUMInter-domain
Routing
Binary
UDP and TCPMostly TCP
T.120
Annex G/H.225.0, TRIP, ENUM
What SIP cannot provide?
SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services.
SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol.
SIP cannot, and does not, provide any kind of network resource reservation capabilities.
SIP Protocol原理 35
SIP in IP Multimedia
SIP Protocol原理 36
Applications
SDP/SDPng
HTTP SMTP SAPSIP RTSP
TCP/SCTP TCP/UDP UDP
RTP/RTCP
RSVP
IPv4/IPv6 with Mobility, DiffServ and Multicast
• Common Addressing, user@domain(URI & URL)• Text-based and Encoding Format• Same Request-Response Model,
and Response Codes• MIME for Flexible Payload• DNS for Address Mapping
Easy to Do Integrated Servicesby Combining more than OneProtocols
When SIP? Where SIP?
IP Network Communication Understand SIP Protocol
Develop SIP Elements
Deploy SIP Network
Create SIP Services
Mobile Network Communication 3G/All IP Network Session Control
IP Multimedia Subsystem Components
Call Session Control Function (CSCF)
NGN Service Technology
IMS Call Model, OMA service enablers
SIP Protocol原理 37
Next Generation Network
Internet Telecom & Wireless Communication
SIP Protocol原理 38
IP
MGCF
CSCF
T-SGW MGWMGW
PDG
GPRS
CSCFSIP
Server
PSTN
InternetWireless App.Server
3rd Parties App.
WLAN
3G/LTE
SIP Protocol
SIP Basics SIP Network Entities
SIP Network Architecture
SIP Message Message Header
Message Body (SDP)
SIP Communication SIP Message Flows
SIP Entities Behavior
SIP Extensions
SIP Protocol原理 39
SIP Network Entities (1/4)
User Agent (UA) User Agent Client - Initiate SIP Request
User Agent Server - Accepts or rejects call
Network Servers Registrar (as UAS), Proxy, Redirect Server (as UAS)
SIP Protocol原理 40
User
Agent
ServerClient Client Server
RegistrarLocation
Server
Redirect
Server
Proxy
Servers
INVITEREGISTER INVITE INVITEResponse
3XX
INVITE
SIP Network Entities (2/4)
Proxy server Handle requests or forward requests to other servers
Can be used for call forwarding, time-of-day routing, or follow-me services
SIP Protocol原理 41
SIP Network Entities (3/4)
Proxy Server + Location Server
SIP Protocol原理 42
cs.ccu.edu.tw
itri.org.tw
location server
BENS
Honda@AUDI
AUDI(1) INVITE
BMW(2
) h
on
da
(3)
ho
nd
a@
AU
DI
(4) INVITEhonda@AUDI
(5) 200 OK(6) 200 OK
(7) ACK [email protected] (8) ACK honda@AUDI
SIP Network Entities (4/4)
Redirect servers Map the destination address to zero or more new
addresses
SIP Protocol原理 43
SIP Network Architecture
SIP Protocol原理 44
User Agent Server (Callee)
Proxy ServerProxy Server
Proxy Server
Redirect Server
Location Server
SIP Request
SIP Response
RTP Media Stream
User Agent Client (Caller)
SIP Requests
Methods (Commands)
REGISTER: Log in and register the address with a SIP
server
INVITE: Initiate a session
ACK: ACK only when receiving the final response
BYE: Terminate a session
CANCEL: Terminate a pending request
OPTIONS : Allow a UA to query another UA or a proxy
server as to its capabilities
SIP Protocol原理 45
SIP Responses
Status code (A three-digit number) 1xx: Provisional -- request received, continuing to process the
request;
2xx: Success -- the action was successfully received, understood, and accepted;
3xx: Redirection -- further action needs to be taken in order to complete the request;
4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server;
5xx: Server Error -- the server failed to fulfill an apparently valid request;
6xx: Global Failure -- the request cannot be fulfilled at any server.
SIP Protocol原理 46
SIP Session Setup Example
SIP Protocol原理 47
SIP Protocol
SIP Basics SIP Network Entities
SIP Network Architecture
SIP Message Message Header
Message Body (SDP)
SIP Communication SIP Message Flows
SIP Entities Behavior
SIP Extensions
SIP Protocol原理 48
SIP Message
SIP is a text-based protocol and uses the UTF-8 charset (RFC 3629std63) .
A SIP message is either a request from a client to a server,
or a response from a server to a client.
Both types of messages consist of a start-line,
one or more header fields,
an empty line indicating the end of the header fields, and
an optional message-body.
SIP Protocol原理 49
SIP Message Format (1/2)
SIP Protocol原理 50
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP science.fiction.com
From: Fingal <sip:[email protected]>
To: Patric <sip:[email protected]>
Call-ID: [email protected]
Cseq: 1 INVITE
Subject: lunch at La Empenada?
Content-Type: application/sdp (mime)
Content-Length: …
SIP
Header
Payload:
SDP
(MIME type)
SIP/2.0 200 OK
Via: SIP/2.0/UDP science.fiction.com
From: Fingal <sip:[email protected]>
To: Patric <sip:[email protected]>
Call-ID: [email protected]
Cseq: 1 INVITE
Content-Type: application/sdp
Content-Length: …
SIP Response ExampleSIP Request Example
v=0
o=ffl 53655765 2353687637 IN IP4 123.4.5.6
s=Chorizo
c=IN IP4 science.fiction.com
m=audio 5004 RTP/AVP 0 3 5
a=rtpmap:0 PCMU/8000
SIP Message Format (2/2)
Message headers Additional information of the request or response E.g.,
The originator and recipient (From and To headers )Subject headerContent-Length header
Message body Describe the type of session The most common structure for the message body is SDP
(Session Description Protocol). Could include an ISDN User Part message Examined only at the two ends
SIP Protocol原理 51
SIP Messaging Syntax
Text-based Disadvantage – more bandwidth consumption Similar to HTTP
However, in SIP, the two endpoints are symmetric
SIP messages message = start-line
*message-header CRLF[message-body]
start-line = request-line | status-line The request-line specifies the type of request The response status-line indicates the success or failure
of a given request
SIP Protocol原理 52
SIP Request Start-Line (1/2)
Method SP Request-URI SP SIP-version CRLF
Methods REGISTER
Log in and register the address with a SIP server“all SIP servers” – multicast address (224.0.1.175)Can register with multiple serversCan have several registrations with one server
INVITE, ACKInitiate a session~IAM (initial address message) of ISUPACK only when receiving the final response
SIP Protocol原理 53
SIP Request Start-Line (2/2)
BYETerminate a sessionCan be issued by either the calling or called party
CANCELTerminate a pending requestE.g., an INVITE did not receive a final response
OPTIONSQuery servers about their capabilities
Request-URI The address of the destination
SIP-Version: SIP/2.0
SIP Protocol原理 54
SIP Addressing & Naming
The entities addressed by SIP are users at hosts (SIP
URLs: Uniform Resource Locators)
Augmented Backus-Naur Form described
email-like identifier of the form user@host
user: user name or telephones number
host: domain name or a numeric network address
Examples of SIP URLs user@host
SIP Protocol原理 55
SIP Response Status-Line
SIP Version SP Status Code SP Reason-Phrase CRLF
Status code (A three-digit number) 1XX Informational
2XX Success
3XX Redirection
4XX Request Failure
5XX Server Failure
6XX Global Failure
All responses, except for 1XX, are considered final
Reason-Phrase A textual description of the outcome, presented to the user
SIP Protocol原理 56
Terms: Call & Session
Call Some communication between peers. Identified by a globally unique Call-ID
Session SDP specification: “ A multimedia session is a set of
multimedia senders and receivers and the data streams flowing from senders to receivers.”
SIP Transaction The first SIP request message to a final response. 1 INVITE request + a non-2xx response + ACK 1 INVITE request + a 2xx response 1 Non-INVITE request + 1 final response
SIP Protocol原理 57
Terms: SIP Transaction
SIP Transaction: A SIP transaction occurs between a client and a server, and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.
SIP Protocol原理 58
Message Headers
Provide further information about the message
Example of headers To: The called party
From: The calling party
Call-ID Header: uniquely identifies a specific invitation to a session
Four main categories General headers
Request headers
Response headers
Entity headers
SIP Protocol原理 59
General Headers (1/6)
Used in both requests and responses
Call-ID Header uniquely identifies a specific invitation to a session
Call-ID = (“Call-ID” | “i”) “:” local-id“@”host
local-id = 1 *uric
“host” SHOULD be a fully qualified domain name or a globally routable IP address.
Call-IDs are case-sensitive
All REGISTER requests issued by a single client SHOULD use the same Call-ID, at least within the same boot cycle.
SIP Protocol原理 60
General Headers (2/6)
To Header To = (“To” | “t”) “:” (name-addr | addr-spec) * (“;”addr-
params)
To: The Operator <sip:[email protected]>;tag=28722
To: sip:[email protected]
Requests and responses MUST contain To field.
If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. Otherwise, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response. (to be combined in the Dialog ID)
SIP Protocol原理 61
General Headers (3/6)
Contact Header Provides a URL for use in future communication
regarding a particular session
INVITE request and response
MUST be present for the establishment of a dialog
INVITE 2xx response (from UAS)reachable most directly for future SIP requests
INVITE 3xx response (from redirect server)
the list of alternative locations
An "expires" parameter to indicate the lifetime
SIP Protocol原理 62
General Headers (4/6)
REGISTER requestwhich locations the user is reachable
REGISTER 2xx responsesreturn all current locations
In a SIP INVITE, the Contact header might be different from the From header
An third-party server initiates a multiparty session
SIP Protocol原理 63
General Headers (5/6)
Via Header Prevent request looping.
Ensure replies take the same path.
Requests:
Original request MUST insert Via field(host name, network address, port number).
Subsequent proxy: add its own Via field before
Proxy send a request to a multicast addressadd the “maddr” and “ttl”
Proxy server receive a request containing it’s address.Response with a 482(loop detected)
SIP Protocol原理 64
General Headers (6/6)
Receiver-tagged Via headerVia: SIP/2.0/UDP erlang.bell-telephone.com:5060
Via: SIP/2.0/UDP 10.0.0.1:5060; received=199.172.136.3
Response
First Via header indicate the proxy or client processing the response ?Yes: remove this Via field
No: discard the message
No second Via headerYes: this response is destined for this client
No: processing depends on “maddr” or “receiver-tag”
UAS or redirect server copies the Via into response.
SIP Protocol原理 65
Request/Response Header
Request Headers Apply only to SIP requests
Addition info. about the request or the client
Subject:
Priority: urgency of the request emergency, urgent, normal, or non-urgent
Response Headers Further info about the response that cannot be included
in the status line
Unsupported
Retry-After
SIP Protocol原理 66
Entity Headers
Indicate the type and format of information included in the message body
Content-Length: the length of message body
Content-Type: the media type of message body E.g., application/sdp
Content-Encoding: for message compression
Content Disposition: how a message part should be interpreted session, icon (image), alert (audio), render (text) …
SIP Protocol原理 67
SIP Message Examples
SIP Protocol原理 68
Session Description Protocol
The Most Common Message Body Be session information describing the media to be
exchanged between the parties
SDP, RFC 2327(-> 4566prop), April 1998 (-> July 2006 )
SIP uses SDP in an offer/answer mode. An agreement between the two parties as to the types
of media they are willing to share
RFC 3264 (An Offer/Answer Model with SDP)
To describe how SDP and SIP should be used together
SIP Protocol原理 69
Usage of SDP with SIP
SIP and SDP make a wonderful partnership for the transmission of session information
SIP provides the messaging mechanism for the establishment of multimedia sessions
SDP provides a structured language for describing the sessions The entity headers identifies the message body
SIP Protocol原理 70
The Structure of SDP
Text-based Protocol
The Structure of SDP Session Level Info
Name of the sessionOriginator of the sessionTime that the session is
to be active Media Level Info
Media typePort numberTransport protocolMedia format
SIP Protocol原理 71
Originator and Session IDProtocol Version
Session NameSession Time
Media Name and TransportConnection Information
Media Name and TransportConnection Information
Session Description
Session Level Information
Media Description 1
Media Description 2
SDP Syntax
A number of lines of text
In each line field=value
field is exactly one character
case-significant
Session-level fields
Media-level fields Begin with media description field (m=)
SIP Protocol原理 72
Mandatory Fields
v=(protocol version)
o=(session origin or creator)
s=(session name), a text string For multicast conference
t=(time of the session), start time & stop time For pre-arranged multicast conference
m=(media) Media type
The transport port
The transport protocol
The media format, an RTP payload formatSIP Protocol原理 73
Optional Fields (1/3)
Some optional fields can be applied at both session and media levels. The value applied at the media level overrides that at
the session level
i=(session information) A text description At both session and media levels It would be somewhat superfluous, since SIP already
supports the Subject header.
u=(URI of description) Where further session information can be obtained Only at session level
SIP Protocol原理 74
Optional Fields (2/3)
e=(e-mail address) Who is responsible for the session Only at the session level
p=(phone number) Only at the session level
c=(connection information) Network type, address type & connection address At session or media level
b=(bandwidth information) In kilobits per second At session or media level
SIP Protocol原理 75
Optional Fields (3/3)
r=(repeat times) A regularly scheduled session to be repeated How often and how many times
z=(timezone adjustments) For regularly scheduled session Standard time and daylight savings time
k=(encryption key) An encryption key or a mechanism to obtain it for the
purposes of encrypting and decrypting the media At session or media level
a=(attributes) Describe additional attributes
SIP Protocol原理 76
Ordering of Fields
Session Level Protocol version (v)
Origin (o)
Session name (s)
Session information (i)
URI (u)
E-mail address (e)
Phone number (p)
Connection info (c)
Bandwidth info (b)
Time description (t)
Repeat info (r)
Time zone adjustments (z)
Encryption key (k)
Attributes (a)
Media level
Media description (m)
Media info (i)
Connection info (c)
Optional if specified at the session level
Bandwidth info (b)
Encryption key (k)
Attributes (a)
SIP Protocol原理 77
Subfields (1/3)
Field = <subfield1> <subfield2> <subfield3>
Origin
Username, the originator’s login id or “-”
session ID, a unique ID: Make use of NTP timestamp
version, a number for this particular session
network type, a text string: IN refers to Internet
address type: IP4, IP6
address, a fully-qualified domain name or the IP address
SIP Protocol原理 78
Subfields (2/3)
Connection Data The network & address at which media will be received
Network type, Address type, Connection address
Media Information Media type - Audio, video, data, or control
Port
Format
List the types of media format to be supported
According to the RTP audio/video profile
m= audio 45678 RTP/AVP 15 3 0
G.728, GSM, G.711
SIP Protocol原理 79
Subfields (3/3)
Attributes To enable additional information to be included Property attribute
a=sendonlya=recvonly
value attributea=orient:landscape used in a shared whiteboard session
rtpmap attributeThe use of dynamic payload typea=rtpmap:<payload type> <encoding name>/<clock rate>
[/<encoding parameters>].m=video 54678 RTP/AVP 98a=rtpmap 98 L16/16000/2
16-bit linear encoded stereo (2 channels) audio sampled at 16kHz
SIP Protocol原理 80
SDP Example
SIP Protocol原理 81
SDP in SIP Messages
INVITE with multiple media streams Unsupported should also be returned with a port
number of zero
An alternative INVITE request
m=audio 4444 RTP/AVP 2 4 15
a=rtpmap 2 G726-32/8000
a=rtpmap 4 G723/8000
a=rtpmap 15 G728/8000
INVITE responsem=audio 6666 RTP/AVP 15
a=rtpmap 15 G728/8000
SIP Protocol原理 82
SDP in SIP Flow (1/2)
SIP Protocol原理 83
Daniel<sip:[email protected]> Boss<sip:[email protected]>
INVITE sip:[email protected] SIP/2.0From: Daniel<sip:[email protected]>; tag = abcd1234To: Boss<sip:[email protected]>CSeq: 1 INVITEContent-Length: 213Content-Type: application/sdpContent-Disposition: session
v=0o=collins 123456 001 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 2a=rtpmap 2 G726-32/8000m=audio 4666 RTP/AVP 4a=rtpmap 4 G723/8000m=audio 4888 RTP/AVP 15a=rtpmap 15 G728/8000
a
bSIP/2.0 200 OK…
SDP in SIP Flow (2/2)
SIP Protocol原理 84
Daniel<sip:[email protected]> Boss<sip:[email protected]>
SIP/2.0 200 OKFrom: Daniel<sip:[email protected]>; tag = abcd1234To: Boss<sip:[email protected]>; tag = xyz789CSeq: 1 INVITEContent-Length: 163Content-Type: application/sdpContent-Disposition: session
v=0o=collins 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 0 RTP/AVP 2m=audio 0 RTP/AVP 4m=audio 6666 RTP/AVP 15a=rtpmap 15 G728/8000
ACK sip:[email protected] SIP/2.0From: Daniel<sip:[email protected]>; tag = abcd1234To: Boss<sip:[email protected]>; tag = xyz789CSeq: 1 ACKContent-Length: 0
b
c
dConversation
SIP&SDP Offer/Answer Model
Re-INVITE is issued when the server replies with more than one codec. With the same dialog identifier (To and From headers,
including tag values), Call-ID and Request-URI
The session version is increased by 1 in o= line of message body.
A mismatch 488 or 606 - Not Acceptable
A Warning header with warning code 304 (media type not available) or 305 (incompatible media type)
Then the caller issues a new INVITE request.
SIP Protocol原理 85
Offer/Answer Flow (1/2)
SIP Protocol原理 86
INVITE sip:[email protected] SIP/2.0CSeq: 1 INVITEContent-Length: 183Content-Type: application/sdpContent-Disposition: session
v=0o=collins 123456 001 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 2 4 15a=rtpmap 2 G726-32/8000a=rtpmap 4 G723/8000a=rtpmap 15 G728/8000a=inactive
Daniel<sip:[email protected]> Boss<sip:[email protected]>
b
a
SIP/2.0 200 OKCSeq: 1 INVITEContent-Length: 157Content-Type: application/sdpContent-Disposition: session
v=0o=collins 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 6666 RTP/AVP 4 15a=rtpmap 4 G723/8000 a=rtpmap 15 G728/8000a=inactive
Offer/Answer Flow (2/2)
SIP Protocol原理 87
Daniel<sip:[email protected]> Boss<sip:[email protected]>
d
c
INVITE sip:[email protected] SIP/2.0CSeq: 2 INVITEContent-Length: 126Content-Type: application/sdpContent-Disposition: session
v=0o=collins 123456 002 IN IP4 station1.work.coms=c=IN IP4 station1.work.comt=0 0m=audio 4444 RTP/AVP 15a=rtpmap 15 G728/8000
ACK sip:[email protected] SIP/2.0From: Daniel<sip:[email protected]>; tag = abcd1234To: Boss<sip:[email protected]>; tag = xyz789CSeq: 1 ACKContent-Length: 0
SIP Protocol
SIP Basics SIP Network Entities
SIP Network Architecture
SIP Message Message Header
Message Body (SDP)
SIP Communication SIP Message Flows
SIP Entities Behavior
SIP Extensions
SIP Protocol原理 88
SIP Session Setup Example
SIP Protocol原理 89
i) Register(Bob)
SIP Protocol原理 90
ii) 200 OK
SIP Protocol原理 91
1) INVITE(A->Pa)
SIP Protocol原理 92
2) INVITE(Pa->Pb)
SIP Protocol原理 93
3) INVITE(Pb->B)
SIP Protocol原理 94
4) 180 Ringing(B->Pb)
SIP Protocol原理 95
5) 180 Ringing(Pb->Pa)
SIP Protocol原理 96
6) 180 Ringing(Pa->A)
SIP Protocol原理 97
7) 200 OK(B->Pb)
SIP Protocol原理 98
8) 200 OK(Pb->Pa)
SIP Protocol原理 99
9) 200 OK(Pa->A)
SIP Protocol原理 100
10) ACK(A->B)
SIP Protocol原理 101
11) Media
SIP Protocol原理 102
12) BYE(B->A)
SIP Protocol原理 103
13) 200 OK (A->B)
SIP Protocol原理 104
SIP Registration Example
Registration Via:
From: and To:
Call-ID: host-specific
Contact:
* (to remove all registrations, valid only if expires=0)
Content-Length:
Zero, no msg body
CSeq:
A response must use the same CSeq as used in the request.
Expires:
0, unreg
SIP Protocol原理 105
Initial Registration (1/2)
SIP Protocol原理 106
SIP Registrar (as UAS)Register F1
401 Unauthorized F2
REGISTER sip:register.com SIP/2.0
Via: SIP/2.0/UDP user.com:5060
From: John <sip:client@ register.com>
To: John <sip:client@ register.com>
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: John <sip:[email protected]>
Contact: <sip:[email protected];user=phone>
Contact: tel:+886-3-1234567
Content-Length: 0
F1SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP user.com:5060
From: John <sip:client@ register.com>
To: John <sip:client@ register.com>
Call-ID: [email protected]
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="MCI WorldCom SIP",
domain="wcom.com",
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
stale=FALSE,
algorithm=MD5
Content-Length: 0
F2
register.comuser.com
John
Initial Registration (2/2)
SIP Protocol原理 107
REGISTER sip:register.com SIP/2.0
Via: SIP/2.0/UDP user.com:5060
From: John <sip:client@ register.com >
To: John <sip:client@ register.com >
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: John <sip:[email protected]>
Contact: <sip:[email protected];user=phone>
Contact: tel:+886-3-1234567
Authorization:Digest username=“John", realm="MCI WorldCom SIP",
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
uri="sip:ss2.wcom.com",
response="dfe56131d1958046689cd83306477ecc"
Content-Length: 0
F3SIP/2.0 200 OK
Via: SIP/2.0/UDP user.com:5060
From: John <sip:client@ register.com>
To: John <sip:client@ register.com>
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: John <sip:[email protected]>
Contact: <sip:[email protected];user=phone>
Contact: tel:+886-3-1234567
Content-Length:0
F4
Register F1
401 Unauthorized F2
REGISTER F3
200 OK F4
SIP Registrar (as UAS)[email protected]
register.com
user.com
John
Updated Registration (1/2)
SIP Protocol原理 108
[email protected] Registrar (as UAS)
REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: <sip:[email protected]
tel.com:3890;transport=udp>
Expires: 7200
F1
REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 2 REGISTER
Contact: *
Expires: 0
F2
Register F1 (2hours)
REGISTER F2 (clear all)
saturn.bell-tel.combell-tel.com
200 OK
200 OK
Updated Registration (2/2)
SIP Protocol原理 109
[email protected] SIP Registrar (as UAS)
REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP pluto.bell-tel.com
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 1 REGISTER
Contact: sip:[email protected]
F4
Register F1 (2hours)
REGISTER F2 (clear all)
200 OK saturn.bell-tel.com
bell-tel.com
Updated REGISTER F3 (register again,moved)
200 OK
REGISTER sip:bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 3 REGISTER
Contact: sip:[email protected]
F3
200 OK
pluto.bell-tel.com
UAC Behavior (1/2)
SIP Protocol原理 110
Generating the Request mandatory request line
method
Request-URI: initial Request-URI set as the To field
SIP version = SIP/2.0
mandatory six header fields in any request To: the desired recipient of the request
From: the initiator of the request
Cseq: a sequence number and a requested method
Call-ID: a unique identifier to group together a series of messages
Max-Forwards: to limit the number of hops
Via: identifies the location where the response is to be sent
UAC Behavior (2/2)
SIP Protocol原理 111
Sending the Request If the first element in the route set indicated a strict
router, the procedures MUST be applied to the Request-URI of the request.
Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present.
the destination MUST be determined by applying the DNS procedures
UAS Behavior
Generating the Response
mandatory request line SIP version = SIP/2.0
Status code
mandatory five header fields in the response
From, Call-ID, Cseq, Via: Copy them from request
To: the same as that in the request if a request contained a To
tag in the request.
Otherwise, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response. (to be combined in the Dialog ID)
SIP Protocol原理 112
Invitation
A two-party call Content-Type:
application/sdp A dialog
To identify a peer-to-peer relationship between two user agents
A dialog IDTag in FromTag in ToCall-ID
CSeq:# unchanged in the same
transaction ACK: no response for it
SIP Protocol原理 113
Boss<sip:[email protected]>Daniel<sip:[email protected]>
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]>; tag=44551Contact: sip:[email protected]: Boss<sip:[email protected]>Call-ID: [email protected]: 1 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)
a
b
SIP/2.0 180 RingingVia:SIP/2.0/UDP station1.work.com;branch=z9hG4bK123From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>; tag=11222Contact: sip:[email protected]: [email protected]: 1 INVITEContent-Length: 0
c
SIP/2.0 200 OKVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>; tag=11222Contact: sip:[email protected]: [email protected]: 1 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)
d
ACK sip:[email protected] SIP/2.0Via:SIP/2.0/UDP station1.work.com;branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>; tag=11222Call-ID: [email protected]: 1 ACKContent-Length: 0
Conversation
Termination of a Call
Cseq: # Has changed
SIP Protocol原理 114
CSeq Header (1/2)
A general-header field to each request.
CSeq = “CSeq” “:” 1*DIGIT SP Method 1*DIGIT : 32-bit unsigned integer
Consecutive requests: same Call-ID, diff. Header Monotonically increasing and contiguous sequence number
Retransmissions of the same request carry the same sequence number, but an INVITE with a different message body or different header fields (a “re-invitation”) acquires a new, higher sequence number.
SIP Protocol原理 115
CSeq Header (2/2)
A server MUST echo the CSeq value from the request.
User agent server Remember the highest CSeq with the same Call-ID. Discard a lower CSeq value.
ACK and CANCEL contain the same CSeq value as the INVITE request.
BYE request with higher CSeq value.
Parallel search: same CSeq value
SIP Protocol原理 116
UA to UA Call Flow (1/3)
SIP Protocol原理 117
[email protected] INVITE F1
100 Trying F2
180 Ringing F3
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP today.com:5060From: John <sip:[email protected]>To: Mary <sip:[email protected]>Call-ID: [email protected]: 1 INVITEContact: John <sip:[email protected]>Content-Type: application/sdpContent-Length: 147
v=0o=John 2890844526 2890844526 IN IP4 today.coms=Session SDPc=IN IP4 100.101.102.103t=0 0m=audio 49172 RTP/AVP 0a=rtpmap:0 PCMU/8000
F1SIP/2.0 100 Trying
Via: SIP/2.0/UDP today.com:5060
From: John <sip:[email protected]>
To: Mary <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
F2
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP today.com:5060
From: John <sip:[email protected]>
To: Mary <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
F3
John
Mary
today.com
tomorrow.com
UA to UA Call Flow (2/3)
SIP Protocol原理 118
100 Trying F2
180 Ringing F3
200 OK F4
ACK F5
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP today.com:5060
From: John <sip:[email protected]>
To: Mary <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
F5
SIP/2.0 200 OK
Via: SIP/2.0/UDP today.com:5060
From: John <sip:[email protected]>
To: Mary <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: Mary <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 147
v=0
o=Mary 2890844527 2890844527 IN IP4 tomorrow.com
s=Session SDP
c=IN IP4 110.111.112.113
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
F4
John
Mary
RTP Mediatoday.com
tomorrow.com
UA to UA Call Flow (3/3)
SIP Protocol原理 119
100 Trying F2
180 Ringing F3
200 OK F4
ACK F5
RTP Media
BYE F6
200 OK F7
SIP/2.0 200 OKVia: SIP/2.0/UDP tomorrow.com:5060From: Mary <sip:[email protected]>To: John <sip:[email protected]>Call-ID: [email protected]: 1 BYEContent-Length: 0
F7 BYE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP tomorrow.com:5060From: Mary <sip:[email protected]>To: John <sip:[email protected]>Call-ID: [email protected]: 1 BYEContent-Length: 0
F6
John
Mary
today.com
tomorrow.com
SIP OPTIONS Method
OPTIONS Request Determine the capabilities of a potential called party
Accept header field SHOULD be included
to indicate the type of message body the sender wishes to receive in the response
OPTIONS Response Allow Header
Indicate the SIP methods that the receiver can handle
Supported Header
Indicate the SIP extensions that can be supported
SIP Protocol原理 120
OPTIONS Flow
SIP Protocol原理 121
Daniel<sip:[email protected]> Boss<sip:[email protected]>
b
aOPTIONS sip:[email protected] SIP/2.0Via: SIP/2.0/UDP Station1.work.com; branch=z9hG4bK7890123From: Daniel<sip:[email protected]>; tag=lmnop123To: Boss<sip:[email protected]>Call-ID: [email protected]: Daniel<sip:[email protected]>CSeq: 1 OPTIONSAccept: application/sdpContent-Length: 0
SIP/2.0 200 OKVia: SIP/2.0/UDP Station1.work.com; branch=z9hG4bK7890123From: Daniel<sip:[email protected]>; tag=lmnop123To: Boss<sip:[email protected]>; tag=xyz5678Call-ID: [email protected]: 1 OPTIONSAllow: INVITE, ACK, CANCEL, OPTIONS, BYEContent-Length: 146Content-Type: application/sdp
v=0o=manager 45678 001 IN IP4 station2.work.coms=c=IN IP4 station2.work.comt=0 0m=audio 0 RTP/AVP 4 15a=rtpmap 4 G723/8000 a=rtpmap 15 G728/8000
Require Header
Client uses it to tell Server about options.
If Server not understand the option, MUST return 420(Bad Extension) and list those options in the Unsupported header.
Example:
C S INVITE sip:[email protected] SIP/2.0
Require: com.example.billing
Payment: sheep_skins, conch_shells
S CSIP/2.0 420 Bad Extension
Unsupported: com.example.billing
SIP Protocol原理 122
Redirect Servers
An alternative address 302, Moved temporarily
Contact header
Another INVITE Same Call-ID,
Same To
CSeq ++
SIP Protocol原理 123
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK124Max-Forwards: 70From: Daniel<sip:[email protected]>; tag=44551Contact: sip:[email protected]: Boss<sip:[email protected]>Call-ID: [email protected]: 2 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)
c
d
ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>Call-ID: [email protected]: 1 ACK
Boss<sip:[email protected]>Daniel<sip:[email protected]>
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]>; tag=44551Contact: sip:[email protected]: Boss<sip:[email protected]>Call-ID: [email protected]: 1 INVITESubject: VacationContent-Length: xxxContent-Type: application/sdpContent-Disposition: session(message body)
a
bSIP/2.0 302 Moved TemporarilyVia:SIP/2.0/UDP station1.work.com;branch=z9hG4bK123From: Daniel<sip:[email protected]>; tag=44551To: Boss<sip:[email protected]>; tag=11222Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]
Redirect Server
Proxy Servers
Numerous proxies can reside in a chain between caller & callee.
Via: Record the path taken by a request Loop detected, 482 (status code) For a response
The 1st Via: header, Checked, and Removed Branch: used to distinguish between multiple responses
to the same requestForking Proxy: Issue a single request to multiple
destinations
SIP Protocol原理 124
Proxy Call Flow (1/2)
SIP Protocol原理 125
Boss<sip:[email protected]> Daniel<sip:[email protected]>
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 70From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE
a
b
SIP/2.0 100 TryingVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE
c
sip:Server.work.com
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE
SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]
SIP/2.0 200 OK...
e
d
Proxy Call Flow (2/2)
SIP Protocol原理 126
Boss<sip:[email protected]> Daniel<sip:[email protected]>
ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7891Max-Forwards: 70Route: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 ACK
e
f
sip:Server.work.com
ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz2Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7891Max-Forwards: 69From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 ACK
SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]
g
Terms: Loop & Spiral
Spiral: A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error, unlike a loop.
A typical cause for this is call forwarding. A user calls [email protected]. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to [email protected]. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, a valid condition.
SIP Protocol原理 127
Loop Detect
SIP Protocol原理 128
Proxy1
Proxy4
Proxy3
Proxy2
UA1
Request message
482 Loop detect
loop detect
Spiral
SIP Protocol原理 129
Proxy1
Proxy4
Proxy3
Proxy2
UA1
spiral
UA2
Request message
Record-Route Header
Two consecutive requests may not pass through the same proxy
A Proxy might require that it remains in the signaling path. In particular, for a stateful proxy
Record-Route: Each proxy server adds its SIP-URI to the beginning of the
Record-Route list. UAS copies the Record-Route header field unchanged
into the response. The info in the Record-Route is used in subsequent
requests related to the same call.
SIP Protocol原理 130
Route Header
Route: Determine the request route.
UAC copies the Record-Route header into a Route header field of subsequent requests within the same call leg, reversing the order.
The Route = the Record-Route in reverse order
Each proxy server removes the first entry of Route
Use it as Request-URI (if strict routing)
Route the request to the UAS.
SIP Protocol原理 131
Terms: Parallel/Sequential Search
In a parallel search, a proxy issues several requests to possible user locations upon receiving an incoming request.
Rather than issuing one request and then waiting for the final response before issuing the next request as in a sequential search, a parallel search issues requests without waiting for the result of previous requests.
A 2xx or 6xx class final response always terminates a sequential search.
SIP Protocol原理 132
Forking Proxy
“fork” requests
A user is registered at several locations ;branch=xxx
In order to handle such forking, a proxy must be stateful.
SIP Protocol原理 133
Forking Proxy Flow (1/2)
SIP Protocol原理 134
Boss<sip:[email protected]>pc1
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 70From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE
a
b
SIP/2.0 100 TryingVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE
c
sip:Server.work.com
INVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK123Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE
dINVITE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 INVITE
pc2
Forking Proxy Flow (2/2)
SIP Protocol原理 135
Boss<sip:[email protected]>pc1
e
f
g
sip:Server.work.com
CANCEL sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Max-Forwards: 69Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12Contact: Boss<sip:[email protected]>To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 CANCEL
SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bK456Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]
pc2
SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK789Record-coute: <sip:server.work.com;lr>From: Boss<sip:[email protected]>; tag=ab12To: Daniel<sip:[email protected]>; tag=xyz45Call-ID: [email protected]: 1 INVITEContact: sip:[email protected]
123
Terms: Dialog (1/2)
Dialog (~ call leg in RFC 2543) A dialog represents a peer-to-peer SIP relationship
between two user agents that persists for some time.
The dialog represents a context which facilitates sequencing of messages between the user agents and proper routing of requests between both of them.
A dialog identified at each UA with a dialog ID consists of
a Call-ID value: the Call-ID of the message
a local tag: the tag in the From/To field for UAC/UAS
a remote tag: the tag in the To/From for UAC/UAS.
The dialog ID at each UA in the dialog is not the same.
SIP Protocol原理 136
Terms: Dialog (2/2)
A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called "secure", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer.
A dialog can also be in the "early" state, which occurs when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives.
SIP Protocol原理 137
Terms: Loose Routing
A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field).
A proxy compliant to these mechanisms is also known as a loose router.
Strict routing behavior is not used in this spec.
SIP Protocol原理 138
SIP Dialogs and Routing (1/6)
SIP Protocol原理 139
SIP Dialogs and Routing (2/6)
SIP Protocol原理 140
SIP Dialogs and Routing (3/6)
SIP Protocol原理 141
SIP Dialogs and Routing (4/6)
SIP Protocol原理 142
SIP Dialogs and Routing (5/6)
SIP Protocol原理 143
SIP Dialogs and Routing (6/6)
SIP Protocol原理 144
Terms: B2BUA
A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.
SIP Protocol原理 145
Terms: Location Service
A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s).
It contains a list of bindings of address-of-record keys to zero or more contact addresses.
The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings.
SIP Protocol原理 146
SIP Protocol Structure
The lowest layer is the transport layer. It defines how a client sends requests and receives responses and
how a server receives requests and sends responses over the network.
The second layer is the transaction layer. A transaction is a request sent by a client transaction (using the
transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client.
Stateless proxies do not contain a transaction layer.
The layer above the transaction layer is called the transaction user (TU). Each of the SIP entities, except the stateless proxy, is a transaction
user.
SIP Protocol原理 147
SIP Protocol Structure Example
Assumed that Proxy 1 and Proxy 3 stateful proxy servers and Proxy 2 stateless
SIP Protocol原理 148
4) INVITE (A->P1)
SIP Protocol原理 149
4) INVITE (P1->P2->P3)
SIP Protocol原理 150
4) INVITE (P3->B)
SIP Protocol原理 151
6) 180 Ringing (P1<-P2<-P3)
SIP Protocol原理 152
6) 180 Ringing (A<-P1)
SIP Protocol原理 153
2 Kinds of Proxy Servers
A logic role for SIP environment Can be either stateless or stateful
Stateless Proxy Act as a simple forwarding element.
Forward each request downstream to a single element base on the request.
Forward every response upstream.
Stateful Proxy It is a SIP transaction processing engine.
May fork a request and route it to multiple destinations.
SIP Protocol原理 154
Terms: Stateful Proxy
Stateful Proxy: A logical entity that maintains the client and server transaction state machines defined by this specification during the processing of a request, also known as a transaction statefulproxy. The behavior of a stateful proxy is further defined in Proxy behavior.
A (transaction) stateful proxy is not the same as a call stateful proxy.
SIP Protocol原理 155
INVITE Client Transaction
SIP Protocol原理 156
Calling
Proceeding
Completed
Terminated
Timer A fires
Reset A,
INVITE sent1xx
1xx to TU
INVITE from TU
INVITE sentTimer B fires
or Transport Err.
Inform TU
2xx
2xx to TU
2xx
2xx to TU
Transport Err.
Inform TU
Timer D fires
-
1xx
1xx to TU
300 – 699
ACK SENT,
resp. To TU
300 – 699
ACK SENT
300 ~ 699
ACK sent
resp. to TU
INVITE Server Transaction
SIP Protocol原理 157
Proceeding
Completed
Confirmed
Terminated
INVITE
send response
300 ~ 699 from TU
send response
INVITE
pass INV to TU
send 100 if TU won’t in 200ms
Transport Err.
Inform TU
2xx from TU
send response
Timer H fires
or Transport Err.
Inform TU
Transport Err.
Inform TUTimer I fires
-
INVITE
send response ACK
-
101 ~ 199 from TU
send response
Timer G fires
send response
Client Transaction for BYE/CANCEL/OPTIONS/REGISTER
SIP Protocol原理 158
Initial
Calling
Call
Proceeding
Completed
-
REQUEST
1xx
-
Status
-
1xx
-
Min(T1 * 2n
, T2)or n * T2
REQUEST
status
-
status
-
event
request sent
11 REQUEST sent
n * T2
Request
Server Transaction for BYE/CANCEL/OPTIONS/REGISTER
SIP Protocol原理 159
Initial
Proceeding
Completed
request
1xx
request
2xx
request
1xx
10 * T2
Status change
1xx
Failure Success
success
2xxfailure
>=300
terminated
487
request
status
32s
-
32s
-
Event
Message sent
Confirmed
32s
-
Stateful Proxy Behavior
Proxy a new request Validate the request
Reasonable syntax
URI scheme
Max-Forwards
Loop detection (optional)
Proxy-Require
Proxy-Authorization
Preprocess routing info
Determine request target(s)
Forward the request
Make a copy of the request
Update the Request-URI
Update the Max-Forwards
Optionally add a Record-route header field value
Optionally add additional header fields
Postprocess routing info
Determine the next-hop address, port, and transport
Add a Via header field value
Add a Content-Length header field if necessary
Forward the new request
Set timer C
Process all responses
Remove the topmost Via
Forward the response
Generate necessary CANCEL reqSIP Protocol原理 160
SIP Protocol
SIP Basics SIP Network Entities
SIP Network Architecture
SIP Message Message Header
Message Body (SDP)
SIP Communication SIP Message Flows
SIP Entities Behavior
SIP Extensions
SIP Protocol原理 161
SIP INFO Method
Specified in RFC 2976 For transferring information during an ongoing session
DTMF digits, account-balance information, mid-call signaling information (from PSTN)
Application-layer information could be transferred in the middle of a call.
A powerful, flexible tool to support new services The transfer of DTMF digits
The transfer of account balance information
Pre-paid service
The transfer of mid-call signaling information
SIP Protocol原理 162
SIP Event Notification
Several SIP-based applications have been devised based on the concept of a user being informed of some event E.g., Instant messaging
RFC 3265 has addressed the issue of event notification SUBSCRIBE and NOTIFY
The Event header
SIP Protocol原理 163
Subscriber Notifier
SUBSCRIBE
200 OK
NOTIFY
200 OK
NOTIFY
200 OK
a
b
c
d
e
f
Current stateinformation
Updated stateinformation
SIP Presence (1/3)
A asks to be told when B registers
SIP Protocol原理 164
Registrar, Presence Server,
SIP Presence (2/3)
NOTIFY A that B has <Not Signed In>
SIP Protocol原理 165
Registrar, Presence Server,
SIP Presence (3/3)
NOTIFY A that B has <Signed In>
SIP Protocol原理 166
Registrar, Presence Server,
SIP MESSAGE Method
The IETF working group – SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE)
A new SIP method – MESSAGE This request carries the actual message in a message
body.
A MESSAGE request does not establish a SIP dialog.
SIP Protocol原理 167
Instant Messaging (1/2)
SIP Protocol原理 168
Daniel<sip:[email protected]>Boss<sip:[email protected]> sip:Server.work.com
MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 70From: Boss<sip:[email protected]> To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 MESSAGEContent-Type: text/plainContent-Length: 19Content-Disposition: render
Hello. How are you?
MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890Max-Forwards: 69From: Boss<sip:[email protected]> To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 MESSAGEContent-Type: text/plainContent-Length: 19Content-Disposition: render
Hello. How are you?
SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKxyz1Via: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:[email protected]> To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 MESSAGEContent-Length: 0
SIP/2.0 200 OKVia: SIP/2.0/UDP pc1.home.net; branch=z9hG4bK7890From: Boss<sip:[email protected]> To: Daniel<sip:[email protected]>Call-ID: [email protected]: 1 MESSAGEContent-Length: 0
a
b
c
d
Instant Messaging (2/2)
SIP Protocol原理 169
Daniel<sip:[email protected]>Boss<sip:[email protected]> sip:Server.work.com
MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 70From: Daniel<sip:[email protected]> To: Boss<sip:[email protected]> Call-ID: [email protected]: 1101 MESSAGEContent-Type: text/plainContent-Length: 22Content-Disposition: render
I’m fine. How are you?
MESSAGE sip:[email protected] SIP/2.0Via: SIP/2.0/UDP server.work.com; branch=z9hG4bKabcdVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123Max-Forwards: 69From: Daniel<sip:[email protected]> To: Boss<sip:[email protected]> Call-ID: [email protected]: 1101 MESSAGEContent-Type: text/plainContent-Length: 22Content-Disposition: render
I’m fine. How are you?
SIP/2.0 200 OKVia: SIP/2.0/UDP server.work.com; branch=z9hG4bKabcdVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:[email protected]> To: Boss<sip:[email protected]>Call-ID: [email protected] CSeq: 1101 MESSAGEContent-Length: 0
SIP/2.0 200 OKVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK123From: Daniel<sip:[email protected]> To: Boss<sip:[email protected]>Call-ID: [email protected] CSeq: 1101 MESSAGEContent-Length: 0
ef
g
h
SIP REFER Method
To enable the sender of the request to instruct the receiver to contact a third party With the contact details for the third party included
within the REFER request
For Call Transfer applications
The Refer-to: and Refer-by: Headers
The dialog between Mary and Joe remains established. Joe could return to the dialog after consultation with
Susan.
SIP Protocol原理 170
Call Transfer (1/2)
SIP Protocol原理 171
sip:[email protected] sip:[email protected] sip:[email protected]
REFER sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station1.work.com; branch=z9hG4bK789Max-Forwards: 70From: Mary<sip:[email protected]>; tag=123456 To: Joe<sip:[email protected]>; tag=67890Contact: Mary<[email protected]>Refer-To: Sussan<sip:[email protected]>Call-ID: [email protected]: 123 REFERContent-Length: 0
SIP/2.0 AcceptedVia: SIP/2.0/UDP station1.work.com; branch=z9hG4bK789From: Mary<sip:[email protected]>; tag=123456 To: Joe<sip:[email protected]>; tag=67890Contact: Joe<[email protected]>Call-ID: [email protected]: 123 REFERContent-Length: 0
Invite sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1Max-Forwards: 70From: Joe<sip:[email protected]>; tag=abcxyz To: Susan<sip:[email protected]>Contact: Joe<[email protected]>Call-ID: [email protected]: 567 INVITEContent-Type: application/sdpContent-Length: xxContent-Disposition: session{message body}
a
b
c
Call Transfer (2/2)
SIP Protocol原理 172
sip:[email protected] sip:[email protected] sip:[email protected]
e
fg
SIP/2.0 200 OKVia: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1From: Joe<sip:[email protected]>; tag=abcxyz To: Susan<sip:[email protected]>; tag=123xyzCall-ID: [email protected]: 567 INVITEContent-Type: application/sdpContent-Length: xxContent-Disposition: session{message body}
ACK sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bKxyz1Max-Forwards: 70From: Joe<sip:[email protected]>; tag=abcxyz To: Susan<sip:[email protected]>; tag=123xyzCall-ID: [email protected]: 567 ACKContent-Length: 0
NOTIFY sip:[email protected] SIP/2.0Via: SIP/2.0/UDP station2.work.com; branch=z9hG4bK123Max-Forwards: 70To: Joe<sip:[email protected]>; tag=67890From: Mary<sip:[email protected]>; tag=123456 Contact: Joe<[email protected]>Call-ID: [email protected]: 124 NOTIFYContent-Type: message/sipfrag;version=2.0Content-Length: 15
SIP/2.0 200 OKVia: SIP/2.0/UDP station2.work.com; branch=z9hG4bK123To: Joe<sip:[email protected]>; tag=67890From: Mary<sip:[email protected]>; tag=123456 Call-ID: [email protected]: 124 NOTIFYContent-Length: 0
h
Call Forwarding
On busy
486, busy here
With the same To, User 3 can recognize that this call is a forwarded call, originally sent to User 2.
Contact: header in 200 response
Call-forwarding-on-no-answer Timeout
CANCEL method
SIP Protocol原理 173
INVITE sip:[email protected] SIP/2.0From: sip:user1To: sip:[email protected]: User1CSeq: 1 INVITE
SIP/2.0 100 TryingFrom: sip:user1To: sip:[email protected]: 1 INVITE
INVITE sip:[email protected] SIP/2.0From: sip:user1To: sip:[email protected]: User1CSeq: 1 INVITE
SIP/2.0 486 Busy HereFrom: sip:user1To: sip:[email protected]: 1 INVITE
INVITE sip:[email protected] SIP/2.0From: sip:user1To: sip:[email protected]: 2 INVITE
SIP/2.0 200 OKFrom: sip:user1To: sip:[email protected]: sip:[email protected]: 2 INVITE
SIP/2.0 200 OKFrom: sip:user1To: sip:[email protected]: sip:[email protected]: 1 INVITE
User1 sip:Server.work.com User2 User3
Useful Web Sites
Tech-Invite: A portal for promoting standardization Knowledge
http://www.tech-invite.com/index.html
This new version of the site will have an access control, with membership management.
RFC-Ref http://www.rfc-ref.org/RFC-TEXTS/3261/contents.html
RFC-Ref is no longer maintained
FreeDownload.ishttp://freedownload.is/pdf/ietf-rfc-3261-pdf
Packetizerhttp://www.packetizer.com/ipmc/h323_vs_sip/
SIP Protocol原理 174
Any Question?