osip user manual文档格式.docx

1、SIP transactions SIP sessions Server behavior3. The oSIP Library The goals The development level The parser The state machinesThe transaction manager Who will benefit from oSIP Available ports4. The oSIP parser files SIP-URL Definition and purpose API for SIP-URL API for url_param_t and url_header_t

2、SIP headers Common API for all implemented header. Specific API for To header API for generic paramSIP messages definition and purpose API for SIP message MACROsThe parser HOW-TO. Initialise the parser Allocate a structure create a URL and a Request-URI. Add headers in a message make a string from a

3、 structure free resource in a structureHow to improve the parser performance5. The oSIP state machines Transaction and events Definition and purpose of transaction Definition and purpose of sipevent API The callbacks. Useful MACROs.The finite state machines HOW-TO Initialise the osip stack Allocate

4、and initialize an osip_t element Send events to control transaction Notes for proxy implementationBuild your own architectureBibliographyChapter 1. The SIP protocolSIP is a signaling protocol used to initiate and control multimedia sessions. It is already published by IETF （www.ietf.org） as the rfc2

5、543.SIP is part of the IETF effort to bring telephony on the IP network. It is about to become the standard used by the emerging IP telephony industry. As simple as the mail protocol, it may become as popular.SIP is independent of mediaThe traditional telephony was based on one media. Now, its over.

6、 Your phone will be able to connect to a TV, to a camera, to others phones with different qualities and different codecs. Hopefully, SIP is independent of any media used by the applications. SIP is able to negotiate media used within sessions. Any multimedia application （games, distance learning app

7、lication） can use SIP to set up sessions.SIP is independent of the transport layerSIP is not tight to any transport protocol. This aspect will minimize efforts to interoperate with new third generation networks. Wireless phones are also concerned. A SIP stack perfectly fits the signaling needs of th

8、e new cellulars generation.SIP is extensibleThe rfc2543 defines 6 types of transaction （INVITE, BYE, CANCEL.）. Those transactions are used to negotiate media, set up, modify and terminate calls. Many services are already provided this way but SIP is designed for extensibility and the transactional m

9、odel can be reused （transparently for servers） by new type of transaction to create some supplementary services. Here is a list of possible services:MESSAGE for instant messagingSUBSCRIBE/NOTIFY for presence managementREFER for call-transfer managementSIP transparently supports name mapping and redi

10、rection services, allowing the implementation of ISDN and Intelligent Network telephony subscriber services. These facilities also enable personal mobility.rfc2543.txt （Section 1.1）SIP servers are used to locate users and distribute location （through urls） on demand. This way, end user agents have v

11、ery minimal requirements and still have access to a wide variety of services.Many extensions are already available as draft. Your can also add your personal phone capabilities and remain interoperable with existing servers.Chapter 2. SIP overviewThis section does not intend to fully describe the RFC

12、. It is a fast and incomplete overview of the protocol syntax and behavior.SIP syntaxSIP is a text protocol based on utf8 encoding. （making it more readable and easier to debug） SIP describes a syntax for SIP requests, URL, responses and their headers. The full syntax is available at Columbia in an

13、augmented BNF form.The syntax is borrowed from the MAIL and HTTP syntax. 6 types of requests are defined by SIP. The basic available methods are:INVITEACKCANCELBYEINFOOPTIONSAs you can see in the BNF definition of request （see rfc2543.txt section 3）, SIP is not limited to this short list of methods

14、and includes in its definition the extension-method token. Any other request can be handled by oSIP. NOTIFY and SUBSCRIBE are good examples of new possible methods. These ones are used specifically to provide presence capabilities to your SIP phone without much effort.Example 2-1. INVITE requestINVI

15、TE requests are used to initiate and modify sessions. Here, cha from is calling jack at domain atosc.org. This request should be sent to the proxy server managing atosc.org, it will forward the call to jack at his real IP address.INVITE sip:jacKatosc.org SIP/2.0Via: SIP/2.0/UDP home.sipworld.orgTo:

16、sip:From:chasipworld.orgCall-ID: 35778645354home.sipworld.orgCSeq: 1 INVITEContact:chahome.sipworld.orgContent-type: application/sdpContent-length: 267v=0o=user1 53655765 2353687637 IN IP4 128.3.4.5s=Mbone Audioi=Discussion of Mbone Engineering Issuese=mbonec=IN IP4 128.3.4.5t=0 0m=audio 3456 RTP/AV

17、P 0a=rtpmap:0 PCMU/8000SIP transactionsIn order to control sessions, SIP uses transactions. Transactions （INVITE, CANCEL, BYE.） usually result in a modification of a current session. Some other transactions （SUBSCRIBE, NOTIFY.） are not bound to a session. A transaction is composed of one request and

18、 its responses （many informational responses and one final response）. The following headers: To, From, Call-ID and CSeq are used to identify messages within a transaction.As SIP can use unreliable transport protocol （UDP is recommended on the IP network）, SIP also defines retransmission rules for me

19、ssages within a transaction.Example 2-2. INVITE transactionThis is the most basic call flow showing the initiation of a session. Only two SIP User Agents （UAC/UAS） are involved. （retransmissions are hidden） UAC1 UAS2 jacks | INVITE | initiate a |-| Bobs call | | Phone starts | 180 Ringing| ringing |

20、-| | 180 Ringing| |SIP sessionsTransactions are used by user agent as means to control sessions. A session is always initiated by an INVITE. SIP defines a large set of answer codes. A proxy may answer you the well known 404 User Not found as for an HTTP error. Errors have different levels. A transac

21、tion can fail but still proposes new locations to try. Responses from class 3xx serve as redirection mechanism. 4xx, 5xx and 6xx responses are respectively reserved for client error, server error and global failure.Example 2-3. A complete sessionFirst, both user agents must send a REGISTER to a regi

22、strar. In the following example, the proxy also support registration.This session is initiated with an INVITE transaction to join jack at . A redirection to jacks office is made by the redirect server of . UA1 understands the redirection and sends a new INVITE towards the real User Agent （UA2） curre

23、ntly used by jack at office.atosc.org. UA2 first rings and jack accepts the call with a 200 OK response. After several minutes, jack and bob want to use their new cameras. The session is modified with an INVITE sent by jack to negotiate new parameters for video. The session is finally ended by bob.

24、BOB Jack （atosc.org） UA1 PROXY UA2 | REGISTER | . |-| . | 200 OK | .-| . . . .later. . . . . | REGISTER | . | | INVITE jack . |302 Moved temporarily . | ACK | . | INVITE jackoffice.atosc.org | | audio | |- | 180 Ringing |-| | ACK jackoffice.atosc.org | . .later . . | INVITE bob | | audio + video | |

25、 ACK bobbob.home.org | | BYE jackoffice.atosc.org | | |SIP defines behaviors for proxy, redirect and registrar server. For complete information, please read the RFC.Usually, a user agent sends its requests to an outbound proxy. As users do not know the current location of their correspondent, they u

26、se for the sip url a username and a domain. The outbound proxy （where firewall capabilities can be inserted） uses DNS SRV RECORDS to find servers belonging to the requested domain. Once the server is found, the request is forwarded. This server is the inbound proxy of the correspondent. If the user is available, its application must have registered its location before, so the proxy is now able to forward the request to