RFC learning notes--5245 ICE & 3261 SIP

----------------------------------------------------------------------------

RFC list:

3550 (RTP/RTCP)-3711 (SRTP)-5245 (ICE)-3261 (SIP)-4575 (sip-conference)-4566 (SDP)

5389 (Stun)-5766 (Turn)-6455 (WebSocket)-6865 (FEC)-2616 (HTTP)

----------------------------------------------------------------------------

One, RFC 5245 ICE Study Notes

----------------------------------------------------------------------------

1, Offer/answer model

----------------------------------------------------------------------------

2, ICE Step:

1) Generate candidate address (1. Public network 2.NAT Reflection 3.Relay forwarding address) Generate candidates

2) Local peer-to-peer exchange candidate addresses, complete connectivity checks. Local & Peer Exchange candidates via SDP, then do connectivity checks

3) Sort by priority sorting candidates

4) Freezing candidate address Frozen candidates

5) Safety Check security for Checks

6) End ice process concluding ice

----------------------------------------------------------------------------

3. STUN (Request/response model)

1) Binding message Format

2) Binding request/binding response

3) Three types of stun applications are currently defined:

Interactive Connectivity Establishment (ICE) [Mmusic-ice], interactive connection established

client-initiated connections for SIP [Sip-outbound], client-initiated connection for SIP

NAT Behavior Discovery [behave-nat],nat Behavior Discovery

----------------------------------------------------------------------------

4. TURN

1) relayed Transport Address:turn The transport address on the server for client and peer relay data.

TURN Server Transport The transport address on the Address:turn server for the client to send stun messages to the server.

Peer Transport Address: The server sees the peer-to-side transport addresses, and when the peer is behind a NAT, the server reflects the transfer address to the end.

Allocation: The relay transport address is provided to the client through the allocate request, in addition to the relay state, there are licensing and time-out timers, and so on.

5-tuple: Five tuples, including a combination of client IP address and port, server IP address and port and transport protocol (including UDP, TCP, TLS).

Channel number is associated with a peer transport address, and once a channel number is bound to a peer-to-end transport address, the client and server can exchange data using a channel data message with a greater bandwidth effect.

Permission: One peer allows the use of its IP address and transport protocol to send data to the turn server, and the server is relayed to the appropriate client only for traffic that is sent from the peer and matches an already existing license.

Realm: A string within the server that describes a server or content that tells the client which combination of user names and passwords can be used for authentication requests.

Nonce: The server randomly selects a string that is included in the digest to be quoted. To prevent relay attacks, the server should regularly change the nonce.

2) Method:

0x003 Allocate

0x004 Refresh

0x006 Send

0x007 Data

0x008 createpermission

0x009 Channelbind

Ii. RFC 3261 SIP Learning Notes

1.SDP (RFC 4566)

1) for exchanging parameters

2) content is divided into three parts session description, Time description and Media description (m-line)

3) The SDP is used to describe the media properties of the session, usually carried in the message body of the SIP protocol, based on the text encoding method

Format

         Session Description v= (protocol version) o= (originator and session identifier) s= (s Ession name) i=* (Session information) u=* (URI of description) e=* (email address) p=* (p Hone number) c=* (connection information-not required if included in all media) b=* (zero or more bandwidth information lines) one or more time descriptions ("t=" and "r=" lines; see below) z=* (t  IME Zone Adjustments) k=* (encryption key) a=* (zero or more session attribute lines) zero or more       Media Descriptions Time Description t= (time the session is active) r=* (zero or more repeat times) Media description, if present m= (media name and transport address) i=* (media title) c=* ( Connection information--optional if included at session level) b=* (zero or more bandwidth Informat Ion lines) k=* (Encryption key) a=* (zero or more media attribute lines) 

----------------------------------------------------------------------------

2. SIP

1) Request/respones Application-level text protocol

Both SIP and XMPP are application-layer protocols that are used primarily to send voice and instant Messaging im on the internet.

RFC3261 defines the sip,rfc3920 definition of XMPP. XMPP comes from an instant messaging system, while SIP resembles voice and video communication.

XMPP adds the jingle extension protocol to support connection-oriented business, such as voice and video, while SIP adds a simple protocol to support the instant messaging business.

The SIP protocol is a client/sever protocol, so there are two types of SIP messages: A request message and a response message.

A request message is a message that the SIP client sends to the server in order to activate a specific operation.

2). Request:

The common SIP request messages are as follows:

INVITE: Indicates that the calling user initiates a session request and invites other users to join a session. It can also be used to update a session after a call is established (at this point the invite is also known as Re-invite).

ACK: The client confirms to the server that it has received a final response to the invite request.

BYE: Indicates terminating an already established call.

Cancel: Cancels the request before it receives the final response to the request and has no effect on the completed request.

Register: Represents the address information that the client registers with the SIP server to be listed in the To field.

OPTIONS: Represents the information and functions that are called by the query.

----------------------------------------------------------------------------

Example:

INVITE Sip:[email protected] sip/2.0

VIA:SIP/2.0/UDP Pc33.atlanta.com;branch=z9hg4bk776asdhds

Max-forwards:70

To:bob <sip:[email protected]>

From:alice <sip:[email protected]>;tag=1928301774

Call-id: [Email protected]

cseq:314159 INVITE

Contact: <sip:[email protected]>

Content-type:application/sdp

content-length:142

----------------------------------------------------------------------------

3). Respones:

100 Trial Call (Trying)

180 Ringing (ringing)

181 calls are forward (call is Being forwarded)

200 successful response (OK)

302 Temporary migration (Moved temporarily)

400 error requests (Bad request)

401 Unauthorized (Unauthorized)

403 Prohibition (Forbidden)

404 user does not exist (not Found)

408 Request Timeout (ask timeout)

480 Temporary unmanned answer (temporarily unavailable)

486 line Busy (Busy here)

504 Server timeout (server time-out)

600 full Busy (Busy Everywhere)

----------------------------------------------------------------------------

Example:

sip/2.0 OK

VIA:SIP/2.0/UDP server10.biloxi.com

; branch=z9hg4bknashds8;received=192.0.2.3

VIA:SIP/2.0/UDP bigbox3.site3.atlanta.com

; branch=z9hg4bk77ef4c2312983.1;received=192.0.2.2

VIA:SIP/2.0/UDP pc33.atlanta.com

; branch=z9hg4bk776asdhds; received=192.0.2.1.

To:bob <sip:[email PROTECTED]>;TAG=A6C85CF

From:alice <sip:[email protected]>;tag=1928301774

Call-id: [Email protected]

cseq:314159 INVITE

Contact: <sip:[email protected]>

Content-type:application/sdp

content-length:131

----------------------------------------------------------------------------

RFC learning notes--5245 ICE & 3261 SIP