1. Signaling & Network Control 7th Semester
SIP Tutorial
Signaling & Network Control 7th Semester

2. Why packet switching? Why SIP?
Technology evolution of PSTN

3. Session Initiation Protocol Overview
Application Layer Signaling Protocol
Used to establish, modify, and terminate multimedia sessions
Part of Internet Multimedia Architecture
Can use UDP, TCP, TLS, SCTP, etc.
Based on HTTP (Web)
Similar text-based structure
Uses URIs (Uniform Resource Indicators)
Applications include (but not limited to):
Voice, video, gaming, instant messaging, presence, call control, etc.
SIP sessions involve one or more participants and can use unicast or multicast communication.
SIP is a key component of the Internet Multimedia Architecture. Other protocols including SDP, RTP, DNS, etc are needed to implement a complete service.
SIP was designed based on one of the most scalable and deployed Internet protocols Hyper Text Transport Protocol (HTTP) the underlying protocol of the World Wide Web (WWW).
SIP is about much more than just voice – supports all media.

4. SIP entities User Agent User Agent Client Proxy Server Redirect server
User Agent Server
Proxy Server
Redirect server
Registrar

5. SIP Elements – User Agents
Capable of sending and receiving SIP requests.
UAC – User Agent Client
UAS – User Agent Server
End Devices
SIP phone
PC/laptop with SIP Client
PDA
mobile phone
PSTN Gateways
are a type of User Agent
DNS Server
Location Server
DNS
SIP
Inbound Proxy Server
Outbound Proxy Server
SIP
SIP
User Agents (UAs) are the endpoints in a SIP network – they originate and terminate SIP requests and responses. They can be implemented as SIP phones, PC/laptop clients, PDAs, cell phones, or even as a PSTN gateway.
SIP
Media (RTP)
User Agent A
User Agent B

6. SIP Elements – Proxy Servers
DNS Server
Location Server
Forward or “proxy” requests on behalf of User Agents
Consult databases:
DNS
Location Server
Types:
Stateless
Transaction Stateful
Call Stateful
No media capabilities
Ignore SDP.
Normally bypassed once dialog established, but can Record-Route to stay in path.
DNS
SIP
Inbound Proxy Server
Outbound Proxy Server
SIP
SIP
SIP proxy servers are the intermediary servers that help UAs establish sessions using SIP. They typically consult databases and perform SIP routing (proxying) on behalf of UAs. They are catagorized based on they type of state information they keep – a stateless proxy keeps no state, a transaction stateful proxy only keeps state on pending transactions, while a call stateful proxy keeps state for the entire duration of a SIP session.
SIP
Media (RTP)
User Agent A
User Agent B

7. SIP Elements – Other Servers
Location Server
Database of locations of SIP User Agents
Queried by Proxies in routing
Updated by User Agents by Registration
DNS Server
SRV (Service) Records used to locate Inbound Proxy Servers
DNS Server
Location Server
DNS
SIP
Inbound Proxy Server
Outbound Proxy Server
SIP
SIP
Location Servers and DNS servers are two examples of databases often queried by SIP proxies (although DNS is often also queried by UAs). Location Servers are SIP registration databases, built by registrar servers. SIP can utilize DNS queries to resolve URIs using A (Address), SRV (Service), or NAPTR (Naming Authority Pointer Records) resource records.
SIP
Media (RTP)
User Agent A
User Agent B

8. SIP Client and Server SIP Elements are either A User Agent acts as a
User Agents (end devices that initiate and terminate media sessions)
Servers (that assist in session setup)
Proxies: Decides next hop and forwards request
Registrars: Accepts REGISTER requests from clients
Redirect servers : Sends address of next hop back to client
SIP Gateways:
To PSTN for telephony interworking
To H.323 for IP Telephony interworking
A User Agent acts as a
Client when it initiates a request (UAC)
Server when it responds to a request (UAS)

9. SIP Addressing Uses Internet URLs Uniform Resource Locators
Supports both Internet and PSTN addresses
General form is
To complete a call, needs to be resolved down to
Examples:
sip:J.T. Kirk

10. SIP Requests and Responses
SIP Responses use a numerical code and a “reason phrase”
Classes:
1xx Informational
2xx Success
3xx Redirection
4xx Client Error
5xx Server Error
6xx Global Failure
SIP Request types are called “methods”
Methods in base spec:
INVITE
ACK
OPTIONS
CANCEL
BYE
REGISTER
SIP is a client/server protocol that uses a request/response structure. Requests are called “methods”. Responses have a numerical code and a reason phrase – many are borrowed from HTTP including the common “404 Not Found” response. (Not all HTTP response codes are valid in SIP – only those defined in RFC 3261.)
Example: 404 Not Found

11. Related Protocol: RTP RTP – Real-time Transport Protocol
Used to transport media packets over IP
RTP adds a bit-oriented header containing:
name of media source
timestamp
codec type
sequence number
Defined by H. Schulzrinne et al, RFC 1889.
Profiles defined by RFC 1890.
RTCP for exchange of participant and quality reports.

12. SIP Call Setup Attempt Scenario
DNS Server
Location Server
1. A “dials” SIP AOR URI User Agent A sends INVITE to outbound Proxy Server.
2. Outbound Proxy sends 100 Trying response.
Inbound Proxy Server
Outbound Proxy Server
1. INVITE
Contact: A
SDP A
Trying
In this SIP call setup attempt scenario, A wishes to call B and “dials” the AOR URI of B. User Agent A generates an INVITE and sends it to its default outbound proxy.
This proxy address can be manually configured or looked up using DNS.
The proxy server immediately returns a 100 Trying provisional response to indicate that it has received the INVITE but that the request is still pending.
User Agent A
User Agent B (Not Signed In)

13. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
3. Outbound Proxy does DNS query to find proxy server for mci.com domain
4. DNS responds with IP address of mci.com Proxy Server
Inbound Proxy Server
Outbound Proxy Server
1. INVITE
Contact: A
SDP A
Trying
The proxy server performs a DNS query and utilizes SRV records to locate the SIP proxy server for the destination domain.
User Agent A
User Agent B (Not Signed In)

14. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
5. Outbound Proxy sends INVITE to Inbound Proxy Server.
6. Inbound Proxy sends 100 Trying response.
5. INVITE
Contact: A
SDP A
Inbound Proxy Server
Outbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Trying
The proxy server the forwards (proxies) the INVITE to that proxy server for the destination domain which also immediately responds with a 100 Trying.
The 100 Trying response is not forwarded by the proxy server back to User Agent A – multiple 100 Trying responses do not convey an new information. As a result, the 100 Trying response is defined to only be a “hop-by-hop” response that is never proxied.
User Agent A
User Agent B (Not Signed In)

15. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
7. LS Query: B?
8. Response: Not Signed In
7. Inbound Proxy consults Location Server.
8. Location Server responds with “Not Signed In.”
5. INVITE
Contact: A
SDP A
Inbound Proxy Server
Outbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Trying
The inbound proxy server consults a location server for B’s current registration information. B is not currently signed in, so the location server returns this information.
User Agent A
User Agent B (Not Signed In)

16. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
7. LS Query: B?
8. Response: Not Signed In
9. Inbound Proxy sends 480 Temporarily Unavailable response.
10. Outbound Proxy sends ACK response.
5. INVITE
Contact: A
SDP A
Inbound Proxy Server
Outbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Temporarily Unavailable
10. ACK
Trying
The proxy server uses this information to generate a 480 Temporarily Unavailable response.
This response receives an immediate ACK (Acknowledgement request) from the other proxy server.
This INVITE/failure-response/ACK exchange completes the SIP transaction between the proxy servers.
User Agent A
User Agent B (Not Signed In)

17. SIP Call Setup Attempt Scenario
DNS Server
Location Server
3. DNS Query: mci.com?
4. Response:
7. LS Query: B?
8. Response: Not Signed In
11. Outbound Proxy forwards 480 response to A.
12. A sends ACK response.
5. INVITE
Contact: A
SDP A
Inbound Proxy Server
Outbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Temporarily Unavailable
10. ACK
Trying
Temporarily Unavailable
The proxy then forwards the 480 back to User Agent A and receives an ACK, completing the transaction between them. The ACK is not forwarded by the proxy as it has already sent an ACK in the previous exchange.
12. ACK
User Agent A
User Agent B (Not Signed In)

18. User Agent B (Not Signed In)
SIP Presence Example
DNS Server
Presence Server
1. A wants to be informed when B signs on, so sends a SUBSCRIBE
2. Outbound Proxy forwards to Inbound Proxy
3. Inbound Proxy forwards to B’s Presence Server
3. SUBSCRIBE
2. SUBSCRIBE
Inbound Proxy Server
Outbound Proxy Server
1. SUBSCRIBE
A wishes to receive a notification when B signs in and is available for communication.
User Agent A sends a SUBSCRIBE request requesting to be notified when B is available. The previous DNS query has been cached, so no new DNS query is needed for the request to be forwarded to the proxy in B’s domain. The inbound proxy then forwards the request to B’s presence server.
User Agent A
User Agent B (Not Signed In)

19. User Agent B (Not Signed In)
SIP Presence Example
DNS Server
Presence Server
3. SUBSCRIBE OK
4. Presence Server authorizes subscription by sending a 200 OK.
5. & OK proxied back to A.
2. SUBSCRIBE
Inbound Proxy Server
Outbound Proxy Server OK
1. SUBSCRIBE OK
The presence server authenticates the subscription and confirms it by sending a 200 OK response which is forwarded back to User Agent A.
No ACK is sent, as ACK is only used to confirm receipt of final responses to INVITE requests – only INVITE transactions use the 3 way handshake.
The SUSBSCIBE/200 OK exchange completes the transaction.
User Agent A
User Agent B (Not Signed In)

20. User Agent B (Not Signed In)
SIP Presence Example
DNS Server
Presence Server
7. Presence Server sends NOTIFY containing current presence status of B (Not Signed In).
8. and 9. NOTIFY is proxied back to A.
10. A acknowledges receipt of notification with OK.
11. & OK is proxied back to B’s Presence Server.
7. NOTIFY
<Not Signed In> OK
8. NOTIFY
<Not Signed In>
Inbound Proxy Server
Outbound Proxy Server OK
9. NOTIFY
<Not
Signed
In> OK
The presence server immediately sends a NOTIFY containing the current state of B, that is, not signed in. User Agent A responds with a 200 OK which is proxied back to the presence server.
This NOTIFY/200 OK exchange completes this transaction.
User Agent A
User Agent B (Not Signed In)

21. SIP Registration Example
DNS Server
Location Server
2. Update database:
B =
1. B signs on to his SIP Phone which sends a REGISTER message containing the FQDN URI of B’s User Agent.
2. Database update is sent to the Location Server
Outbound Proxy Server
Outbound Proxy Server
REGISTER
Contact:
Time passes, then B signs in by send a REGISTER request to through his proxy which forwards it to the registrar server for B’s domain.
The REGISTER contains B’s AOR and a Contact URI which identifies the device that B is currently using.
User Agent A
User Agent B

22. SIP Registration Example
DNS Server
Location Server
3. Location Server database update is confirmed.
4. Registration is confirmed with a 200 OK response.
2. Update database:
B =
3. OK
Outbound Proxy Server
Outbound Proxy Server
1. REGISTER
Contact: OK
Contact:
The location server updates its database with the information and returns a 200 OK to confirm. The Contact URI is also returned in the 200 OK along with an expiration time. To ensure continuous service, B will need to refresh the registration (by sending another REGISTER request) within the time interval.
The REGISTER/200 OK exchange completes the transaction.
User Agent A
User Agent B

23. SIP Presence Example
DNS Server
Presence Server
13. Presence Server learns of B’s new status from the Location Server and sends a NOTIFY containing new status of B (Signed In).
14. & 15. NOTIFY is proxied back to A.
16. A acknowledges receipt of notification with 200 OK.
17. & OK is proxied back to Presence Server.
13. NOTIFY
<Signed In> OK
14. NOTIFY
<Signed In>
Inbound Proxy Server
Outbound Proxy Server OK
15. NOTIFY
<Signed In> OK
The presence server is informed of the change in B’s availability and sends a NOTIFY to User Agent A containing this new information. The 200 OK response of User Agent A is proxies back to the presence server.
User Agent A
User Agent B

24. SIP Instant Message Scenario
1. A sends an Instant Message to B saying “Can you talk now?” in a MESSAGE request.
2., 3. & 4. MESSAGE request is proxied, Location Server queried.
5. Inbound Proxy forwards MESSAGE to B.
6. User Agent B responds with 200 OK.
7. & OK is proxied back to A.
DNS Server
Location Server
3. LS Query: B?
4. Response:
2. MESSAGE
<Can you
talk now?>
Inbound Proxy Server
Outbound Proxy Server OK
1. MESSAGE
<Can you
talk now?> OK
5. MESSAGE
<Can you
talk now?> OK
Knowing that B is now available, A types in an Instant Message (IM) to B. User Agent A generates a MESSAGE request containing the typed text in a message body. The location server query by the inbound proxy server now returns B’s Contact URI and the MESSAGE is routed to B.
User Agent B confirms receipt with a 200 OK. (Note that any typed response by B would not be returned in the 200 OK – it will be sent using a separate MESSAGE request sent from B to A as shown in the next slide.)
User Agent A
User Agent B

25. SIP Instant Message Scenario
1. B sends an Instant Message to A saying “Sure.” in a MESSAGE sent to A’s AOR URI.
2. & 3. DNS Server is queried.
4. Outbound Proxy forwards MESSAGE to Inbound Server.
5. & 6. Location Server is queried.
7. Inbound Proxy forwards to A.
8. User Agent A responds with 200 OK.
9. & OK is proxied back to B.
Location Server
DNS Server
5. LS Query: A?
6. Response:
2. DNS Query: globalipcom.com?
3. Response:
4. MESSAGE
<Sure.>
Outbound Proxy Server
Inbound Proxy Server OK
7. MESSAGE
<Sure.> OK
1. MESSAGE
<Sure.> OK
B types a reply to A. User Agent B generates a MESSAGE request and sends it to its local proxy. The proxy consults DNS to locate the proxy server for the globalipcom.com domain of A. The MESSAGE request is then forwarded to this proxy server which then forwards it to User Agent A. A 200 OK reply is sent which is proxied back to User Agent B.
User Agent A
User Agent B

26. SIP Call Setup Attempt Scenario
DNS Server
Location Server
1. to 5. A retries INVITE to B which routes through two Proxy Servers.
6. Location Server responds with the FQDN SIP URI of B’s SIP Phone.
7. Inbound Proxy Server forwards INVITE to B’s SIP Phone.
5. LS Query: B
6. Response:
3. INVITE
Contact: A
SDP A
Inbound Proxy Server
Outbound Proxy Server
Trying
1. INVITE
Contact: A
SDP A
Trying
7. INVITE
Contact: A
SDP A
A again attempts to establish a session with B by sending an INVITE. This time, the INVITE is forwarded to User Agent B by the inbound proxy server.
User Agent A
User Agent B

27. SIP Call Setup Scenario
DNS Server
Location Server
8. User Agent B alerts B and sends 180 Ringing response.
9. & Ringing is proxied back to A.
Ringing
Inbound Proxy Server
Outbound Proxy Server
Ringing
Ringing
User Agent A being alerting user B and sends a 180 Ringing provisional response which is proxied back to User Agent A. User Agent A informs A that alerting is taking place, possibly by generating local ringtone.
User Agent A
User Agent B

28. SIP Call Setup Scenario
DNS Server
Location Server
11. B accepts call and User Agent B sends 200 OK response.
12. & OK is proxied back to A.
Ringing
Inbound Proxy Server
Outbound Proxy Server OK
Contact: B
SDP B
Ringing OK
Contact: B
SDP B OK
Contact: B
SDP B
Ringing
A accepts the call, so User Agent A sends a 200 OK success response which is proxied back to A.
Since the media is sent directly between A and B, it is possible that B’s “Hello” may reach A before the 200 OK. To avoid this clipping, User Agent A must be prepared to receive and play any RTP media packets as soon as the INVITE is sent.
Likewise, User Agent B must be prepared to receive and play media packets before the ACK from User Agent A is received.
The INVITE/200 OK completes the transaction (the ACK is not part of the same transaction for a success class response).
User Agent A
User Agent B

29. SIP Call Setup Scenario
DNS Server
Location Server
14. ACK is sent by A to confirm setup call bypassing proxies.
Media session begins between A and B!
Ringing
Inbound Proxy Server
Outbound Proxy Server OK
Contact: B
SDP B
Ringing OK
Contact: B
SDP B OK
Contact: B
SDP B
Ringing
In this example, neither proxy server inserts a Record-Route header field, so the ACK sent by User Agent B is sent to the Contact URI contained in the 200 OK sent by User Agent B, which bypasses the two proxies.
This ACK is a separate transaction, not related to the INVITE/200 OK transaction of the previous slide.
14. ACK
Media (RTP)
User Agent A
User Agent B

30. SIP Call Hold (re-INVITE)
DNS Server
Location Server
15. B places A on hold by sending a re-INVITE.
16. A accepts with a 200 OK.
17. B sends ACK to A.
No media between A and B.
Inbound Proxy Server
Outbound Proxy Server
15. INVITE
SDP a=sendonly
B decides to attempt to transfer A to another party, C. In preparation, B places A on “hold” by sending a re-INVITE (an INVITE sent within an existing dialog) in which the media stream is set to sendonly. (B also applies local mute, so no RTP packets are exchanged between A and B.) OK
SDP A
17. ACK
User Agent A
User Agent B

31. SIP Call Transfer Scenario
DNS Server
Location Server
18. B transfers A to C using REFER.
19. Transfer is accepted by A with 202 Accepted response.
20. Notification of trying transfer is sent to B in NOTIFY.
21. B sends 200 OK response to NOTIFY
Inbound Proxy Server
Outbound Proxy Server
B initiates the transfer by sending a REFER to A which receives a 202 Accepted response. This success-class response indicates that User Agent A has received the REFER and will attempt the transfer. However, the final outcome of the refer (success or failure) is not yet known.
User Agent B sends an initial NOTIFY indicating that it will be trying to send an INVITE to User Agent C, which receives a 200 OK response.
18 REFER Refer-To:
Accepted
20. NOTIFY <100 Trying>
User Agent A OK
User Agent B

32. SIP Call Transfer Scenario
DNS Server
Location Server
1. to 5. A sends new INVITE to C which routes through two Proxy Servers.
6. Location Server responds with the FQDN SIP URI of C’s SIP Phone.
7. Inbound Proxy Server forwards INVITE to C’s SIP Phone.
5. LS Query: C?
6. Response:
3. INVITE
Contact: A
Ref-By: B
SDP A
Inbound Proxy Server
Outbound Proxy Server
Trying
7. INVITE
Contact: A
Ref-By: B
SDP A
1. INVITE
Contact: A
Ref-By: B
SDP A
Trying
Acting upon the REFER, User Agent A generates an INVITE and sends it to the URI in the Refer-To header field in the REFER. A Referred-By header field contains B URI, telling C that A has been transferred by B.
User Agent C
User Agent A
User Agent B

33. SIP Call Transfer Scenario
DNS Server
Location Server
8. User Agent C alerts C and sends 180 Ringing response.
9. & Ringing is proxied back to A.
11. C accepts call and sends 200 OK response.
12. & OK is proxied back to A.
14. ACK is sent by A to confirm setup call.
Media session between A and C begins.
Ringing
Inbound Proxy Server
Outbound Proxy Server OK
Contact: C
SDP C OK
Contact: C
SDP C
Ringing OK
Contact: C
SDP C
Ringing
User Agent C begins alerting, sending 180 Ringing. C accepts the call and User Agent C sends a 200 OK. Again, no proxy Record-Routes, so the ACK is sent directly to C’s Contact URI.
14. ACK
User Agent C
Media (RTP)
User Agent A
User Agent B

34. SIP Call Transfer Scenario
DNS Server
Location Server
20. Notification of successful transfer is sent to B in NOTIFY.
21. B sends 200 OK response to NOTIFY
22. B hangs up by sending a BYE.
OK response to BYE is sent.
Inbound Proxy Server
Outbound Proxy Server
User Agent A sends a NOTIFY to User Agent B informing him that the transfer was completed successfully. As a result, User Agent B disconnects with A by sending a BYE.
If the transfer had failed, User Agent B could have attempted another transfer by sending another REFER or could have taken A off hold and continued the media session.
20. NOTIFY <200 OK> OK
22. BYE
User Agent A
User Agent B OK

35. SIP Session Establishment and Call Termination
Media Stream
From the RADVISION whitepaper on SIP

36. Call Proxying
From the RADVISION whitepaper on SIP

37. SIP Call Redirection
From the RADVISION whitepaper on SIP

38. SIP Requests SIP Requests (Messages) defined as:
Method SP Request-URI SP SIP-Version CRLF (SP=Space, CRLF=Carriage Return and Line Feed)
Example: INVITE SIP/2.0

39. } SIP Requests Example Required Headers (fields):
Via: Shows route taken by request.
Call-ID: unique identifier generated by client.
CSeq: Command Sequence number
generated by client
Incremented for each successive request
INVITE SIP/2.0
Via: SIP/2.0/UDP host.wcom.com:5060
From: Alan Johnston
To: Jean Luc Picard
Call-ID:
CSeq: 1 INVITE }
Uniquely identify this session request

40. SIP Responses SIP Responses defined as (HTTP-style):
SIP-Version SP Status-Code SP Reason-Phrase CRLF (SP=Space, CRLF=Carriage Return and Line Feed)
Example: SIP/ Not Found
First digit gives Class of response:

41. SIP Responses: 1xx-3xx

42. SIP Responses: 4xx

43. SIP Responses: 5xx-6xx

44. SIP Responses Example Required Headers:
Via, From, To, Call-ID, and CSeq are copied exactly from Request.
To and From are NOT swapped!
SIP/ OK
Via: SIP/2.0/UDP host.wcom.com:5060
From: Alan Johnston
To: Jean Luc Picard
Call-ID:
CSeq: 1 INVITE

45. SIP Headers - Partial List

46. SIP Headers - Continued

47. SIP Headers - Continued

48. Via Headers and Routing
Via headers are used for routing SIP messages
Requests
Request initiator puts address in Via header
Servers check Via with sender’s address, then add own address, then forward. (if different, add “received” parameter)
Responses
Response initiator copies request Via headers.
Servers check Via with own address, then forward to next Via address

49. SIP Firewall Considerations
Firewall Problem
Can block SIP packets
Can change IP addresses of packets
TCP can be used instead of UDP
Record-Route can be used:
ensures Firewall proxy stays in path
A Firewall proxy adds Record-Route header
Clients and Servers copy Record-Route and put in Route header for all messages

50. SIP Message Body Message body can be any protocol
Most implementations:
SDP - Session Description Protocol
RFC /98 by Handley and Jacobson
Used to specify info about a multi-media session.
SDP fields have a required order
For RTP - Real Time Protocol Sessions:
RTP Audio/Video Profile (RTP/AVP) payload descriptions are often used

51. Authentication & Encryption
SIP supports a variety of approaches:
end to end encryption
hop by hop encryption
Proxies can require authentication:
Responds to INVITEs with 407 Proxy-Authentication Required
Client re-INVITEs with Proxy-Authorization header.
SIP Users can require authentication:
Responds to INVITEs with 401 Unathorized
Client re-INVITEs with Authorization header

52. SIP Mobility Support 4 Mobile Host SIP Redirect Server 5 SIP Proxy
Foreign Network
Home
Network 3 1 2 6 7
1 INVITE
moved temporarily
3, 4 INVITE
5, 6 OK
7 Data
Corresponding
Host
Global: Wire and wireless
No tunneling required
No change to routing

53. SIP Mobility Pre-call mobility Mid-call mobility
Mobile host (MH) can find SIP server via multicast REGISTER
MH acquires IP address via DHCP
MH updates home SIP server
Mid-call mobility
MH->CH: New INVITE with Contact and updated SDP
Re-registers with home registrar

54. SIP Summary SIP is: SIP is not: Relatively easy to implement
Gaining vendor and carrier acceptance
Very flexible in service creation
Extensible and scaleable
Appearing in products right now
SIP is not:
Going to make PSTN interworking easy
Going to solve all IP Telephony issues (QoS)

55. Comparison with H.323
H.323 is another signaling protocol for real-time, interactive
H.323 is a complete, vertically integrated suite of protocols for multimedia conferencing: signaling, registration, admission control, transport and codecs.
SIP is a single component. Works with RTP, but does not mandate it. Can be combined with other protocols and services.
H.323 comes from the ITU (telephony).
SIP comes from IETF: Borrows much of its concepts from HTTP. SIP has a Web flavor, whereas H.323 has a telephony flavor.
SIP uses the KISS principle: Keep it simple stupid.

56. SIP/SS7 MSC Call Flow