DOC

Author Guidelines for 8

By Tyler Austin,2014-07-11 16:42
6 views 0
Author Guidelines for 8 ...

    Integration of SIP VoIP and Messaging Systems with AccessGrid and H.323

    Wenjun Wu, Ahmet Uyar, Hasan Bulut, Geoffrey Fox

    Community Grid Computing Laboratory, Indiana University

    wewu@indiana.edu, auyar@mailbox.syr.edu, hbulut@indiana.edu, gcf@indiana.edu

    Indiana Univ Research Park, 501 North Morton Street, Suite 222, Bloomington, IN47404

    Abstract and functionality. Therefore it is very important to create

    a more general framework to cover the wide range of collaboration solutions and enable users from different In order to build an integrated collaboration system communities to collaborate. over heterogeneous collaboration environments, we In [2], we propose a Web-Services framework, named proposed a collaboration Web-Service framework XGSP (XML based General Session Protocol) for an XGSP and initially applied it to audio-video (A/V) audio/video collaboration system to solve the issue of conferencing. SIP is a very important collaboration heterogeneity and integration. Based on this framework, standard, which has been widely adopted by many large this paper focuses on how to integrate SIP based companies for IP telephony, Instant Messaging as well as collaboration resources, and how to make SIP clients or desktop videoconferencing. In this paper, we developed a servers communicate with AccessGrid as well as H.323 XGSP based system to integrate SIP based collaboration systems. systems with AccessGrid and H.323 based systems. This The paper is organized in the following way: In prototype can support various clients and servers from Section 2, the XGSP framework and the design issues different collaboration technologies such as SIP and about SIP Web-Services are introduced. Section 3 AccessGrid as well as H.323 in the same conference. presents the design of the SIP Web-Services prototype system in detail. The implementation and application Keywords: SIP, XGSP, Instant Messaging, examples are introduced in section 4. And we give the Videoconferencing, Web Services conclusion and future work in section 5. 1. Introduction 2. XGSP & SIP Web-Services Collaboration and videoconferencing systems have 2.1 SIP Architecture and Service become a very important application in the Internet.

     There are various solutions to such multimedia

    The Session Initiation Protocol (SIP) defines how to communication applications, among which H.323 [7],

    establish, maintain and terminate Internet sessions SIP [12], and Access Grid [1] are well-known. H.323 is

    including multimedia conferences. The architecture of an umbrella standard designed by ITU for multimedia

    SIP based systems is showed in Figure 1. conferencing over IP-based networks. It is the most

    widely adpoted standard by the videoconferencing RegistrarLocationRedirectindustry. SIP is a standard of IETF, which is an ServerServerServeralternative solution to H.323, especially for Voice over IP.

    SIP has been applied in IP telephony, Instant Messageing

    (IM) and videoconferencing. AccessGrid is a derivation SIPfrom MMUSIC conference [4], which uses MBONE tools Clientto support large scale videoconferences based on high-

    SIP PROXYspeed multicast networks. SERVERIt will bring substantial benefits to Internet users if we

    can build an integrated collaboration environment, which SIP MCSIP MPSIPcombines conferencing, streaming, instant messaging as ClientSIP MCUwell as other collaborations into a single easy-to-use,

    intuitive environment. However, at present all these systems have features that sometimes can be compared Fig 1 SIP System Architecture but often they make implicit architecture and A SIP system usually includes SIP clients, a SIP Proxy implementation assumptions that hamper interoperability Server, a Registrar Server, a Location Server, and a

    notifies users of the status of their buddies. It is very Redirect Server as well as a SIP Multipoint Control Unit useful to integrate them into XGSP collaboration (MCU). The SIP Proxy Server primarily plays the role of systems. However IM mostly works for private chats routing, enforcing policy of call admission. The proxy between two or more people. Only the persons in the interprets and if necessary, rewrites specific parts of a buddy list can join or be invited into a IM session. So request message before forwarding it. The SIP registrar IM is suitable for informal and ad-hoc chats rather accepts REGISTER requests and places the information than room-based or scheduled sessions. XGSP it receives in the requests into the location service for the framework mainly supports formal and scheduled domain it handles. In addition, the SIP Proxy provides collaborations, which requires a chat room instant messaging service, forwarding SIP Presence environment hosting many participants in one or Event messages and SIP text messages to SIP clients. many discussions. Therefore, we must find a way to

    combine both of the collaboration patterns. 2.2 XGSP Web-Services Framework ? XGSP framework can not only integrate SIP clients but also other SIP communities into the whole In this framework, we divide an A/V collaboration collaboration system. SOAP connections should be system into three parts: clients, session servers and established between the XGSP Manager Server and multipoint communication channels providers. We need other SIP collaboration servers so that the SIP MCU to connect the components from different systems in two as well as SIP proxy server can be commanded to ways: firstly the system allows each client whether it is connect with XGSP servers. And since SOAP MBONE, H323 or SIP to build RTP channels with the communication is slower than other protocols such multipoint communication RTP channel providers; as JavaRMI and CORBA, we have to ensure it will secondly the system connects all the channel providers not affect the performance of the collaboration. together to form a global RTP communication infrastructure.

    2.3 XGSP Servers for integrating various The first goal requires a common session protocol,

    which enables different types of clients and servers to collaboration understand and communicate with each other. We define a XML based protocol, called XGSP (XML Based We have designed a XGSP prototype system, in which General Session Protocol). Each native session command there are two servers supporting the main framework of in SIP, H.323 as well as Access Grid is transformed into XGSP: a Web Server and a XGSP MCU. The XGSP XGSP methods and executed by XGSP servers. Also the MCU is some kind of bridge between H.323/SIP XGSP response is transformed back into the native endpoints and Access Grid clients, supporting both response and returned to the native clients. The centralized channel and decentralized RTP channel in middleware architecture is required for the second goal to the same session. For those unicast-only H323/SIP integrate various RTP multipoint communication servers. endpoints, the XGSP MCU provides unicast audio and Web-services technology seems to be the best candidate video channel, and perform video switch, video mixing for this purpose since it can run across various platforms and audio mixing services. And the XGSP MCU runs an and is easy to be extended and understood. agent in an IP multicast group to communicate with In order to build SIP web-services based on the XGSP Access Grid clients. framework, we need to solve the following issues: The Web server provides a collaboration portal to ? The SIP calling procedure has to be translated into users and system administrators. Users need the web

    XGSP messages. The INVITE, BYE method must be portal to participant in the audio/video collaboration. The

    transformed to the Join/Leave Session Command in user web portal supports the high-level services of the

    XGSP. XGSP collaboration framework, including XGSP ? SIP URIs has to be mapped into XGSP name space. registration, XGSP membership control as well as XGSP

    Each SIP Client should make a registration in the session control. A system administrator can use the web

    SIP Registrar of the local domain. All of these portal to manage the system, for example configuring the

    registrations must be kept in the name storage of the components of the system, and uploading some new

    XGSP system. services and so on. ? SIP Instant Messaging services have to be integrated

    with Chat Room services. SIP framework can 3. Design of SIP Web-Services support IM and presence services, usually

    implemented in the SIP Proxy. IM allows users to

    chat in a real-time way and the presence service

    registrations will be forward to the XGSP naming server XGSP Naming & DirectorySIP Proxy, RegistrarServicesServerfor storage.

    The SIP Gateway needs to register several records for Web ServerServerSQLdifferent active collaboration sessions. For example, if

    there are three sessions created in the Web Server, the XGSP SessionSIPSOAP ConnectionGatewayServerSIP Gateway has to register with the SIP Registrar Server SIPClientswith three session names. When a SIP client wants to

    VideoAudiojoin in an active session, it must send an invitation to the RTP ChannelsServerServerOther SIPServiceSIP URL of that session. Access GridSnapshotCommunityRTP ChannelsCommunitiesServer( Multicast ) Media Server3.2 Instant Messaging & Chat Room Services Fig 2 SIP Web Services Architecture

    IETF IMPP working group defines a standard protocol

    “Model for Presence and Instant Messaging” [9].SIP 3.1 SIP-to-XGSP provides an Event notification mechanism and MESSAGE method to support the model. A SIP Proxy is The figure 2 shows the architecture of SIP Web-used to route SIP MESSAGE as well as other SIP Services. We combine the SIP proxy and the SIP registrar methods among SIP clients. So we need to build a into a single server, and divide the XGSP into two specific SIP Proxy for IM services, which can be different parts: the XGSP Session Server and the XGSP combined with a SIP Registrar into the SIP Server. Media Server, which is the combination of a Multipoint A XGSP session has a chat room, which can be Controller and a Multipoint Processor. The Web Server implemented by building message reflection function can send commands to the Session Server and the inside the SIP Gateway. Since the SIP Gateway has SIP Naming & Directory Server with the support of the SQL “clients” for each active XGSP session, the “clients” can database storage. The SIP Gateway works as a protocol be regarded as chat rooms. Once a SIP client user starts bridge between the SIP Proxy and the XGSP Session an IM session with one of these clients in the SIP Server, redirecting the RTP channels of SIP clients to the Gateway, it joins in the chat session of this XGSP session. XGSP Media Server. The SIP Gateway accepts the MESSAGE sent by this SIP The signaling translator maintains a dedicated TCP client, and forwards it to other IM SIP clients that have connection with XGSP-Session Server for each incoming been in this chat room. Furthermore, the functions of the SIP client, which is called XGSP-connection. SIP chat session can be enhanced by introducing some shell Messages including INVITE and BYE, can be translated commands, for example, the command of listing all the into XGSP messages and transferred over this connection. participants in the session. The procedure is: when the SIP gateway receives an INVITE request from a SIP client, it will send a

    JoinSession message to the XGSP Session Server, and 3.3 HearMe SIP Web-Services get the media description by parsing the SDP body in the INVITE message. After getting an admission response To integrate other SIP communities into the XGSP from the XGSP Session Server, the SIP gateway will system, we need a high-level control level on which the reply to the SIP client with an OK message holding the XGSP collaboration Manager can co-ordinate with the media description of the XGSP MCU. And when the SIP control servers in other SIP communities. And the gateway receives a BYE message, it will send a general A/V media channels are also necessary for LeaveSession message to the Session Server and reply to connecting all the RTP channels in these communities the SIP client after it close the XGSP connection. and individual clients. Such approaches can separate the According to SIP standard, the registration creates control from the multimedia transmission so that the bindings in a location service for a particular domain that slow SOAP connection will only increase the delay of associate an address-of-record URI with one or more building collaboration session. The architecture for the contact addresses. And the SIP registrar usually acts as high-level control level is showed in the Fig 3. The the front end to the location service for a domain, reading XGSP Collaboration Manager uses SOAP messages to and writing mappings based on the contents of send collaboration control commands to Web servers in REGISTER requests. We rely on XGSP naming & SIP, AG and H.323 communities. The XGSP MCU directory service to provide our location resolving, which serves the purpose of bridging all the RTP channels from maintains a database for the whole name space of the these communities. Dedicated RTP channels can be XGSP collaboration system. Therefore, all the

    HearMe Web services include: CreateSession, established between the XGSP MCU and SIP/H.323 DestroySession, ModifySession, QuerySession, MCU as well as AccessGrid multicast groups. Web Service ( WSDL Directory,SOAP Communication)ConnectMCU and DisconnectMCU. All the commands are defined in WSDL format and invoked by the XGSP

    collaboration manager. Fig 4 shows some segments of its

    WSDL definition, which describes the service of CollaborationAGH.323SIPWeb ServerWeb ServerWeb ServerWeb ServiceCreateSession. Manager Server

     AccessH.323SIPGridSessionSession<?xml version=”1.0”?> ServicesServicesServices <definitions name=”HearMeSIPServices RTP Clients targetNamespace=”http://www.hearme.com/audiomcu/service” Media channels xmlns:hearme=”http://www.hearme.com/audiomcu/service” Mbone: VIC/RATxmlns:xsd=”http://www.w3.org/2001/XMLSchema” H.323: Netmeeting,PolycomAudio/Video Media Channel SIP: HearMe, ... xmlns:soap=”http://schemas.xmlsoap.org/wsdl/soap/” Service... xmlns = “http://schemas.xmlsoap.org/wsdl”> <!Type definitions -- > <types> ……</types> Fig 3 Integrating other SIP/H.323 Communities <!- - Message definitions -- > <message name=”CreateSessionRequest”> <part name=”SessionId” type=”xsd:string” /> A Web Server for the SIP community is supposed to <part name=”Max-Particpants” type=”xsd:string” /> <part name=”schedule” type=”hearme: scheduleDate” /> provide some capabilities for local session management </message> and floor control. XGSP collaboration manager can <message name=”CreateSessionResponse”> <part name=”result” type=”xsd:boolean”> invoke these APIs to create a collaboration session across <part name=”reason” type=”xsd:string”> different environments and administration communities, </message> <! Port type definitions -- > and control the collaboration applications. <portType name=”HearMeSIPServicesPortType”> For example, if a user wants to create a session named <operation name=”CreateSession”> <input message=”CreateSessionRequest”> “testsession”, for both AccessGrid users and the SIP <output message=”CreateSessionResponse”> communities, he can define the XGSP session place as </operation> <operation name=”DestroySession”> … </operation> “AG: testroom; SIP: confroom” in order to connect two <operation name=”ModifySession”> … </operation> virtual conference rooms from the AG and SIP <operation name=”QuerySession”> … </operation> <operation name=”ConnectMCU”> … </operation> communities. When the meeting is about to start, the <operation name=”DisconnectMCU”> … </operation> XGSP collaboration manager will activate this ….. “testsession” by starting the AG agent in the XGSP MCU </portType> <! Binding definitions -- > to join in “AG:testroom” and invoking the web services <binding name=”HearMeSipServiceSOAPBinding” of this SIP community so that the MCU in this type=”HearMeSIPServicesPortType”> <soap:binding stype=”rpc” community could dial in the XGSP SIP Gateway and transport=”http://schemas.xmlsoap.org/soap/http ”/> connect to the XGSP MCU. <operation name=”CreateSession”> <soap:operation soapAction=””/> When a collaboration user logs in and joins the XGSP <input> session, he is required to choose which rooms he wants to <soap:body use=”encoded” namespace=” http://www.hearme.com/audiomcu/service” connect and by which collaboration protocol. If he uses encodingStyle=” http://schemas.xmlsoap.org/soap/encoding” /> VIC and RAT and wants to enter “AG: testroom”, his </input> <output> VIC and RAT may be directed to the multicast session of <soap:body use=”encoded” namespace=” “AG: testroom”. If he uses a SIP Messenger and wants to http://www.hearme.com/audiomcu/service” encodingStyle=” http://schemas.xmlsoap.org/soap/encoding” /> enter “SIP: confroom”, his Messenger may be linked to </output> the SIP MCU. Since “AG: testroom” multicast room and </operation> … more binding definition …. “SIP: confroom” have been connected, all the clients in </binding> both of the virtual rooms can make audio collaboration. <! Service definition -- > <service name=”HearMeSIPServices> After the meeting is over, the XGSP collaboration <port name=”CreateSessionmanager can invoke web-services of the SIP community binding=”HearMeSIPServicesSOAPBinding”> again to disconnect the SIP MCU from the XGSP MCU. <soap:address location=”http:// www.hearme.com:8080/axis/services/HearMeSIPServices” /> We use HearMe [6], a SIP based Voice-over-IP system, </port> as an example to illustrate the SIP Web-Services </service> </definitions> interface. Similar interface can also be implemented

    based on other SIP or H.323 collaboration systems.The

    HearMe Talk Server plays the role of the session server

    in other systems and HearMe MCU provides SIP

    signaling and RTP channels for multipoint meetings. The

    Fig 4. HearMe WebService WSDL example

    using ASCP to communicate with the Talk Server. The 4. Implementation and Examples

    AXIS SOAP processor [15] is used to process SOAP We have developed a prototype system to verify and requests and invoke the HearMe services through the refine our SIP web-services framework. It is developed in HearMe Wrapper. Java language and can be deployed in Windows or UNIX This prototype can support all the SIP compatible system. We follow JAIN SIP [8] stack specified by Sun clients. We have tested HearMe clients and Windows for SIP development. NIST [10] is an open source project Messengers. Windows Messenger (MSN) is becoming a and implements SIP JAIN library. The NIST package very popular Instant Messaging client in the Internet, also includes the examples of Proxy-Registrar Server and which can support text, audio, video collaborations and Instant Messageing client. We use the NIST library to connect multiple kinds of servers, including standard SIP develop the SIP Gateway and build our own Proxy Server Proxy and Registrar Servers. We can configure Windows based on the source codes. Messenger to register with the XGSP SIP Proxy and The HearMe SDK provides an interface called Audio Registrar server, and attend the XGSP collaborations. Service Control Protocol (ASCP) between the HearMe The Fig 5 shows the scenario when two Window Talk Server and the HearMe MCU. ASCP is used to Messengers are talking with a RAT client and a HearMe control the various aspects of the HearMe voice services. client. Based on ASCP, we build a HearMe Wrapper implementing the HearMe Web Services interface by

    Fig 5 XGSP Chat&audio collaboration scenario

    In this collaboration scenario, the system talk with the RAT in the AG multicast session and administrator has created a XGSP audio session named HearMe clients in the HearMe conference. ourtestroom for AG:224.10.10.10/6666 and HearMe: ourtestroom. Both of the Messengers have joined in the 5. Conclusion XGSP session “ourtestroom”, and are chatting with each In this paper, we have presented the design and other in this session. And simultaneously they can also implementation of a SIP Web-services system. Under the

    [9] Model for Presence and Instant Messaging, RFC2778, XGSP framework, this system can support SIP clients,

    http://www.ietf.org/rfc/rfc2778.txt Access Grid and H.323 clients in the same meeting,

    [10] NIST SIP, http://snad.ncsl.nist.gov/proj/iptel/. provide Instant Messaging and chat room services to

    [11] Real Time Transfer Protocol (RTP), RFC 1889, Windows Messenger clients, and connect with other SIP

    http://www.ietf.org/rfc/rfc1889.txt communities. Such an integrated collaboration

    [12] Session Initiation Protocol (SIP), RFC 2543, environment greatly benefits those users that want to

    http://www.ietf.org/rfc/rfc2543.txt enter Access Grid world via SIP clients, merge the

    [13] SIP-Sepcific Event Notification, RFC3265, collaboration of videoconferencing and IM into a single

    http://www.ietf.org/rfc/rfc3265.txt environment, and create communication channels for

    [14] Simple Object Access Protocol (SOAP) 1.1, different collaboration communities.

    http://www.w3.org/TR/SOAP/ In the next development, we will enhance the

    [15] Steve Graham, Simeon Simeonov, etc, Building Web capability of this system in the following aspects:

    Services with Java, ISBN0-672-32181-5, Sams (1) In our prototype, single XGSP MCU may become

    publishing. the performance bottleneck for large-scale

    [16] Web Services Description Language (WSDL) 1.1, videoconferences. Narada [3], a distributed event

    http://www.w3.org/TR/wsdl middleware will be introduced to the system to implement a scalable and high-available A/V Event system [5].

    (2) Our prototype supports room-based, scheduled

    collaboration. But many peer-to-peer collaborations need ad-hoc meeting mechanisms. IM seems to be a very promising approach to realize ad-hoc collaboration sessions. We will extend SIP IM to implement this new collaboration pattern.

    6. References

[1] Access Grid, http://www.accessgrid.org

    [2]Geoffrey Fox, Wenjun Wu, Ahmet Uyar, and Hasan Bulut A Web Services Framework for Collaboration and Audio/Videoconferencing, The 2002 International Multiconference in Computer Science and Computer Engineering, Internet Computing(IC’02), June 2002, Las

    Vegas

    [3] Geoffrey C. Fox and Shrideep Pallickara, “The Narada Event Brokering System: Overview and

    Extensions”, proceedings of the 2002 International Conference on Parallel and Distributed Processing Techniques and Applications (PDPTA'02)

    [4] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The Internet Multimedia Conferencing Architecture", Internet Draft, draft -ietf-mmusic -confarch-03.txt, July 2000.

    [5] Hasan Bulut, Geoffrey Fox, Shrideep

    Pallickara,Ahmet Uyar and Wenjun Wu, Integration of NaradaBrokering and Audio/Video Conferencing as a Web Service, IASTED International Conference on Communications, Internet, and Information Technology, November 2002, US Virgin Islands.

    [6] HearMe Audio conference system,

    http://www.hearme.com,

    [7] H.323 ITU Recommendation

    [8] Jain SIP, http://jcp.org/en/jsr/detail?id=125

Report this document

For any questions or suggestions please email
cust-service@docsford.com