Media Resource Broker SIP Client Implementation Agreement MSF-IA-SIP.014-FINAL

Size: px
Start display at page:

Download "Media Resource Broker SIP Client Implementation Agreement MSF-IA-SIP.014-FINAL"

Transcription

1 Media Resource Broker SIP Client Implementation Agreement MSF-IA-SIP.014-FINAL

2 MultiService Forum Implementation Agreement Contribution Number: msf Document Filename: MSF-IA-SIP.014-FINAL Working Group: Protocol and Control Title: Media Resource Broker SIP Client Implementation Agreement Editors: Stuart Walker Leapstone Systems Inc IM Working Group Chairperson: Chris Gallon Date: 14 August 2006 MSF-IA-SIP.014-FINAL Abstract: This is the MSF Implementation Agreement for the SIP interface between a Media Resource Broker and the various client functions that make use of Media Servers. The MultiService Forum (MSF) is responsible for developing Implementation Agreements or Architectural Frameworks which can be used by developers and network operators to ensure interoperability between components from different vendors. MSF Implementation Agreements are formally ratified via a Straw Ballot and then a Principal Member Ballot. Draft MSF Implementation Agreements or Architectural Framework may be published before formal ratification via Straw or Principal Member Ballot. In order for this to take place, the MSF Technical Committee must formally agree that a draft Implementation Agreement or Architectural Framework should be progressed through the balloting process. A Draft MSF Implementation Agreement or Architectural Framework is given a document number in the same manner as an Implementation Agreement. Draft Implementation Agreements may be revised before or during the full balloting process. The revised document is allocated a new major or minor number and is published. The original Draft Implementation Agreement or Architectural Framework remains published until the Technical Committee votes to withdraw it. After being ratified by a Principal Member Ballot, the Draft Implementation Agreement or Architectural Framework becomes final. Earlier Draft Implementation Agreements or Architectural Frameworks remain published until the Technical Committee votes to withdraw them. The use of capitalization of the key words MUST, SHALL, REQUIRED, MUST NOT, SHOULD NOT, SHOULD, RECOMMENDED, NOT RECOMMENDED, MAY or OPTIONAL is as described in section V-B of the MSF Technical Committee Operating Procedures. The goal of the MSF is to promote multi-vendor interoperability as part of a drive to accelerate the deployment of next generation networks. To this end the MSF looks to adopt pragmatic solutions in order to maximize the chances for early deployment in real world networks. To date the MSF has defined a number of detailed Implementation Agreements and detailed Test Plans for the signaling protocols between network components and is developing additional Implementation Agreements and Test Plans addressing some of the other technical issues such as QoS and Security to assist vendors and operators in deploying interoperable solutions. The MSF welcomes feedback and comment and would encourage interested parties to get involved in this work program. Information about the MSF and membership options can be found on the MSF website MultiService Forum. All Rights Reserved. 2 of 18

3 Note: Attention is called to the possibility that use or implementation of this MSF Implementation Agreement may require use of subject matter covered by intellectual property rights owned by parties who have not authorized such use. By publication of this Implementation Agreement, no position is taken by MSF as its Members with respect to the existence or validity of any intellectual property rights in connection therewith, nor does any warranty, express or implied, arise by reason of the publication by MSF of this Implementation Agreement. Moreover, the MSF shall not have any responsibility whatsoever for determining the existence of IPR for which a license may be required for the use or implementation of an MSF Implementation Agreement, or for conducting inquiries into the legal validity or scope of such IPR that is brought to its attention. DISCLAIMER The information in this publication is believed to be accurate as of its publication date. Such information is subject to change without notice and the MultiService Forum is not responsible for any errors or omissions. The MultiService Forum does not assume any responsibility to update or correct any information in this publication. Notwithstanding anything to the contrary, neither the MultiService Forum nor the publisher make any representation or warranty, expressed or implied, concerning the completeness, accuracy, or applicability of any information contained in this publication. No liability of any kind whether based on theories of tort, contract, strict liability or otherwise, shall be assumed or incurred by the MultiService Forum, its member companies, or the publisher as a result of reliance or use by any party upon any information contained in this publication. All liability for any implied or express warranty of merchantability or fitness for a particular purpose is hereby disclaimed. The receipt or any use of this document or its contents does not in any way create by implication or otherwise: Any express or implied license or right to or under any MultiService Forum member company s patent, copyright, trademark or trade secret rights which are or may be associated with the ideas, techniques, concepts or expressions contained herein; nor Any warranty or representation that any MultiService Forum member companies will announce any product(s) and/or service(s) related thereto, or if such announcements are made, that such announced product(s) and/or service(s) embody any or all of the ideas, technologies, or concepts contained herein; nor Any commitment by a MultiService Forum company to purchase or otherwise procure any product(s) and/or service(s) that embody any or all of the ideas, technologies, or concepts contained herein; nor Any form of relationship between any MultiService Forum member companies and the recipient or user of this document. Implementation or use of specific MultiService Forum Implementation Agreements, Architectural Frameworks or recommendations and MultiService Forum specifications will be voluntary, and no company shall agree or be obliged to implement them by virtue of participation in the MultiService Forum. For addition information contact: MultiService Forum California Street, Suite 307 Fremont, CA USA Phone: Fax: info@msforum.org MultiService Forum. All Rights Reserved. 3 of 18

4 Contents 1 MSF Applicability and Scope Differences from MSF Release Modes of Operation MSF Client to Media Resource Broker SIP Interface INVOKING the Media Resource Broker SIP Header Usage Media Resource Broker Responses Considerations for Applications using 3 rd Party Call Control NAT and Firewall traversal QoS aspects Alternate configuration Security aspects Redundancy and resilience References Acknowledgements Figures Figure 1 - Media Resource Broker... 5 Figure 2 - MRB in the Release 3 Architecture... 6 Figure 3 - Monitored mode of operation... 7 Figure 4 Call Rate mode of operation... 7 Figure 5 - Media Resource Broker overflow model Figure 7 - Alternate configuration for QoS resource management MultiService Forum. All Rights Reserved. 4 of 18

5 1 MSF The IETF Session Initiation Protocol defined in RFC3261 and other RFCs is an application layer control protocol for creating, modifying and terminating sessions with one or more participants. The MSF has determined that SIP meets its needs for the interface between the Media Resource Broker and the Client Applications. 2 Applicability and Scope This Implementation Agreement defines the interface between the Media Resource Broker and the Client Applications. Client Application Media Server MRB Client Application Media Servers Client Application Media Servers Figure 1 - Media Resource Broker The Media Resource Broker provides an abstraction, from an allocation perspective, of the physical Media Servers for the different client applications that make use of them. Clients request a Media Server by functionality, the Media Resource Broker which will allocate an appropriate physical Media Server (that provides the requested functionality) to the client. This model enables the sharing of Media Server resources across multiple using clients which can result in significant efficiencies in the quantity of Media Server resources that need to be deployed. The function of the Media Resource Broker itself (how it determines which physical Media Server to allocate to a client) is not detailed in this IA which only covers the interface between the client and the MRB MultiService Forum. All Rights Reserved. 5 of 18

6 In the MSF Release 3 architecture then a number of different client functions make use of Media Servers and will thus make use of the this IA in order to allocate them through the Media Resource Broker. S-CSC SB/SCIM AS MRB MS Parlay / Parlay X GW Service Logic Gateway Figure 2 - MRB in the Release 3 Architecture The Application entities, SIP Application Servers, Parlay / ParlayX Gateway, Service Logic Gateway, make use of Media Servers for services that require Media Server functions. Control layer entities, SB/SCIM and S-CSC also make use of Media Servers for simple functions such as network announcements. 2.1 Differences from MSF Release 2 In Release 2 of the MSF architecture the Media Resource Broker function was an embedded function of the Service Broker. The stand alone Media Resource Broker replaces the class 2 and class 4 services of the Release 2 Service Broker. 2.2 Modes of Operation The Media Resource Broker supports two modes of operation, Monitored mode and Call Rate mode. In Monitored mode of operation the Media Resource Broker remains in the SIP signaling path for both the allocation and release of the Media Server as shown in the figure below MultiService Forum. All Rights Reserved. 6 of 18

7 Client (e.g. Application Server) Media Resource Broker Media Server INVITE 100 Trying 200 OK ACK INVITE 200 OK ACK MEDIA SERVICE FUNCTION CONTROL INTERACTIONS BYE 200 OK BYE 200 OK Figure 3 - Monitored mode of operation In Monitored mode the Media Resource Broker may act as either a SIP Proxy or a Back to Back User Agent (B2BUA). In Call Rate mode of operation then the Media Resource Broker is only in the signaling path for the initial allocation of the Media Server. This reduces the signaling load at the expense of precise knowledge of the state (in terms of number of active sessions) of the Media Server. Call Rate mode of operation is shown in the figure below. Figure 4 Call Rate mode of operation 2006 MultiService Forum. All Rights Reserved. 7 of 18

8 In Call Rate mode of operation the Media Resource broker acts as a proxy and does not include itself in Record-Route headers in the propagated INVITE to the Media Server such that subsequent signaling for the session (beyond the responses to the initial INVITE) is direct between client and Media Server MultiService Forum. All Rights Reserved. 8 of 18

9 3 MSF Client to Media Resource Broker SIP Interface This Implementation Agreement builds upon the MSF Core SIP Profile for Voice over IP. This IA highlights additional requirements and differences from the Core SIP IA and defines behavior of the Media Resource Broker with respect to the SIP interface. Transport The Media Resource Broker MUST support UDP as a transport. Other transports (TCP, SCTP) MAY optionally also be supported. Registration The REGISTER message is not supported by the Media Resource Broker. 3.1 INVOKING the Media Resource Broker Clients invoke the Media Resource Broker by sending an INVITE to it which the Media Resource Broker will propagate to an appropriate Media Server should one be available. The Media Resource Broker allocates Media Servers based on overall availability of Media Server resources within the network and based on any user specific policies over and above this. The definition and enforcement of user specific policies used by the Media Resource Broker are not defined in this IA as they have no impact on the interface itself SIP Header Usage The following sections indicate the expected usage of specific SIP Headers in the INVITE sent to the Media Resource Broker Request-URI The Request-URI of the INVITE sent to the Media Resource Broker indicates the media resources being requested. The MRB MUST support the annc, conf and dialog resources defined in RFC4240. For conf allocations then all concurrently active sessions with the same conference id value will be allocated to the same physical media server. It is the responsibility of the sending client to ensure all requests sharing the same conference-id are directed to the same Media Resource Broker instance. The following additional parameters MAY be included in the Request-URI to further influence the action of the Media Resource Broker. br-conf-size = <n> This parameter is used in conjunction with the conf= Request-URI (from RFC4240) in order to instruct the Media Resource Broker the ultimate size of the conference being requested so an appropriate number of ports can be reserved. This parameter is not propagated to the Media Server itself. br-affinity = <unique id> This parameter can be used to indicate to the Media Resource Broker that multiple requests should be allocated to the same physical Media Server. All concurrently active sessions that share the same unique id should be resolved to the same physical Media Server. This parameter is redundant for conf allocations and is not propagated to the Media Server itself. It is the responsibility of the client issuing the request to ensure both the uniqueness of the <unique id> and to ensure that all requests using the same <unique id> are directed to the same Media Resource Broker instance MultiService Forum. All Rights Reserved. 9 of 18

10 br-mrid= <media server id> This parameter can be used to indicate a request for a specific media server (identified by the <media server id>). How Media Servers are identified through the Media Server Id is left to individual implementations. The parameter is not propagated to the Media Server itself. br-capabilities=<comma separated list of capabilities> This parameter allows the definition of custom media capabilities. When custom capabilities are used then the Media Resource Broker must be configured with the capabilities supported by each Media Server under its allocation control. The request will be resolved to a Media Server supporting all the requested custom capabilities, if not all the capabilities can be supported then the request is rejected. The parameter is not propagated to the Media Server itself FROM The From header SHOULD be used to indicate the party for which the Media Server request is being made (for example which subscriber an Application Server acting on behalf of). If an INVITE is received with the clients own address (for example an application server using its own SIP address) then user level resource policies cannot be supported by the Media Resource Broker P-Charging-Vector If the P-Charging-Vector (defined in the 3GPP RFC 3455) was included in the INVITE received by the Media Resource Broker then it MUST be propagated unaltered to the Media Server itself. The Media Resource Broker SHOULD include the contents of the P-Charging-Vector in any billing event records that it creates P-Charging-Function-Addresses If the P-Charging-Function-Addresses (defined in the 3GPP RFC 3455) was included in the INVITE received by the Media Resource Broker then it MUST be propagated unaltered to the Media Server itself. The Media Resource Broker SHOULD send any billing events it creates to the entity identified in the P- Charging-Function-Addresses header. The actual interface between the Media Resource Broker and the Charging Function is outside the scope of MSF Release Record-Route If the Media Server intends to act in monitored mode for a session and is implemented as a proxy then it MUST include a Record-Route header in order to ensure it receives any subsequent requests for the dialog Resource Priority Header The Media Resource Broker SHOULD support the Resource-Priority header (defined in IETF RFC 4412). If the Resource Priority Header was included in the INVITE received by the Media Resource Broker then it SHOULD be propagated unaltered to the Media Server unless resource priority for Media Servers is wholly provided by the Media Resource Broker itself Unrecognized Headers Any SIP headers received in the INVITE to the Media Resource Broker that are not recognized SHOULD be propagated unaltered in the INVITE to the Media Server MultiService Forum. All Rights Reserved. 10 of 18

11 3.1.2 Media Resource Broker Responses The Media Resource Broker will typically generate an immediate 100 Trying respond to avoid any unnecessary re-sends of the INVITE Successful Allocation If a Media Server can be allocated for the request then the INVITE is propagated to it with a modified Request-URI indicating the specific Media Server and having any Media Resource Broker specific parameters removed. In Monitored mode the Media Resource Broker remains in the SIP path for the duration of the SIP dialog. In Call Rate Mode the Media Resource broker remains in the SIP path only to proxy or relay responses to the original INVITE Temporarily Unavailable If the Media Resource Broker is unable to allocate a Media Server because all of the Media Servers it is managing the allocation for that could serve the request are currently unavailable (i.e. currently allocated to another request) then the Media Resource Broker MUST return a 480 Temporarily Unavailable response indicating that the Media Resource Broker cannot allocate the resource at this particular time Not Acceptable Here If the Media Resource Broker is unable to allocate a Media Server because it does not manage a Media Server with the required capabilities then it MUST return a 488 Not Acceptable Here indicating that the Media Resource Broker is not capable of the requested allocation Moved Temporarily In deployments with multiple Media Resource Brokers then if the Media Resource Broker instance cannot serve the request it MAY respond with a 302 Moved Temporarily response indicating another Media Resource Broker that the client may try. This is shown in the figure below MultiService Forum. All Rights Reserved. 11 of 18

12 Figure 5 - Media Resource Broker overflow model Media Server Error Responses Should the Media Resource Broker attempt to allocate a Media Server but receive an error response from it (4xx,5xx,6xx) then it MAY attempt to allocate a different physical Media Server that can serve the request without notifying the client (thereby insulating it from any failures). The number of Media Server allocation attempts is configurable within the Media Resource Broker, if the number of unsuccessful attempts reaches this value then a 480 response is returned to the Client. 3.2 Considerations for Applications using 3 rd Party Call Control The best practices for SIP application servers performing third party call control (3PCC) are described in RFC3725. In MSF Release 2 then for 3PCC calls where one call leg was to a Media Server then flow I from RFC3725 was recommended because the Media Server could be relied upon to answer the call immediately. While this is still true, flow I does not readily lend itself to the RFC3312 model of QoS allocation used by the MSF R3 network. For that reason it is recommended that applications performing 3PCC use flow III irrespective if whether one leg of the call is to a Media Server or not MultiService Forum. All Rights Reserved. 12 of 18

13 4 NAT and Firewall traversal NAT and Firewall traversal is not anticipated to be required between the Media Resource Broker and the Clients requesting a Media Server. 5 QoS aspects The MSF model for bandwidth allocation is a symmetrical model with each edge signaling element reserving bandwidth from the bandwidth manager for the media that its associated media edge element wishes to transmit. For sessions to media servers then the Media Server acts as a signaling end point and is responsible for the reservation of bandwidth for the media it wishes to transmit.. However Media Servers tend to treat the SIP signaling interface as a control interface (they are slave devices directed by a controlling entity such as an application server) and as such will may not support QoS reservation, in this case the alternate configuration described below could be used (this should be viewed as a short term measure for QoS allocation for sessions to Media Servers). 5.1 Alternate configuration An alternative configuration that can be used in deployments where the Media Server is not able to handle QoS allocation via the Bandwidth Manager is shown in the figure below. Figure 6 - Alternate configuration for QoS resource management In order to enable the end-to-end QoS then an S-SBG is inserted between the MRB and the Media Servers, this handles the RFC3312 pre-conditions and the interface to the Bandwidth Manager. The link between the S-SBG and the MS is considered to be unmanaged in this case (so assumed to be provisioned with sufficient bandwidth), the S-SBG will not propagate the INVITE to the MS until the bandwidth (ingress point to S-SBG) has been reserved MultiService Forum. All Rights Reserved. 13 of 18

14 6 Security aspects This IA assumes that encrypted SIP signaling will not be used between the Media Resource Broker and the Clients requesting a Media Server. 7 Redundancy and resilience The Media Resource Broker is a stateful component (particularly when acting in Monitored mode) and as such is required to meet accepted network reliability levels. Typically five nines % reliability with no single point of failure. Components should perform failover processing themselves without reliance on any external stimulus and with the minimum of impact on any component they interface with (sole reliance on clients resending to an alternate IP address is not a robust mechanism for providing resilience). Mechanism for disaster recovery may also be required in order to cater for larger scale failures (such as loss of a complete site). External intervention to affect DR level switchover is acceptable. 8 References Issuer Reference Title IETF RFC3261 SIP: Session Initiation Protocol IETF RFC4240 Basic Network Media Services with SIP IETF RFC4412 Communications Resource Priority for SIP IETF RFC3455 Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3 rd -Generation Partnership Project (3GPP) IETF RFC3725 Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP) IETF RFC3312 Integration of Resource Management and Session Initiation Protocol (SIP) MSF MSF-IA-SIP.006-FINAL R2 Service Broker to Application Server SIP IA MSF MSF-IA-SIP.012-FINAL R3 SIP Core profile for VoIP 9 Acknowledgements The author wishes to thank Fred Hasle and Randy Howlett of Leapstone Systems for their assistance in producing this IA MultiService Forum. All Rights Reserved. 14 of 18

15 Appendix Example Call Flow Successful Media Server Allocation The flow below shows a basic Media Server allocation by a Media Resource Broker acting as a B2BUA in monitored mode. The Media Server is allocated for an application server in order to conduct a dialog, the application server requests a specific media server with logical Id of MR05. The following IP addresses are used Application Server MRB MS (logical media server id = MR05) INVITE from AS to MRB INVITE sip:dialog@ :5060;br-mrid=mr05 SIP/2.0 P-Charging-Vector: icid-value= @ ;icid-genaddr= ;hop-count=3 Via: SIP/2.0/UDP :6742;branch=z9hG4bKa-3 From: <sip: @leapstone.com>;tag=hssua_ b To: sip: @leapstone.com Call-ID: @ CSeq: 2 INVITE Contact: <sip:vm@ :6742> Route: <sip: :5060;lr> Subject: IVT_AS_Voic _b_INVITE-3 Max-Forwards: 70 Content-Type: application/sdp P-Asserted-Identity: <sip: @leapstone.com> Content-Length: 130 <SDP not shown> 100 Trying from MRB to AS SIP/ Trying Via: SIP/2.0/UDP :6742;branch=z9hG4bKa-3 From: <sip: @leapstone.com>;tag=hssua_ b To: sip: @leapstone.com;tag=leap-z9hg4bka-3 Call-ID: @ CSeq: 2 INVITE Contact: sip:dialog@ :5060 Content-Length: 0 INVITE from MRB to MS INVITE sip:dialog@ :6840 SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK Max-Forwards: MultiService Forum. All Rights Reserved. 15 of 18

16 Subject: IVT_AS_Voic _b_INVITE-3 P-Asserted-Identity: P-Charging-Vector: Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REGISTER,UPDAT E,REFER From: To: Call-ID: CSeq: 1 INVITE Contact: <sip: @ :5060> Content-Type: application/sdp Content-Length: 130 <SDP not shown> 100 Trying from MS to MRB SIP/ Trying Via: SIP/2.0/UDP :5060;branch=z9hG4bK From: <sip: @leapstone.com>;tag=hssua_ To: sip: @leapstone.com Call-ID: @ CSeq: 1 INVITE Contact: <sip: :6840;transport=udp> Route: <sip: :5060;lr> Content-Length: MultiService Forum. All Rights Reserved. 16 of 18

17 200 OK from MS to MRB SIP/ OK P-Charging-Vector: Via: SIP/2.0/UDP :5060;branch=z9hG4bK From: To: Call-ID: CSeq: 1 INVITE Contact: <sip: :6840;transport=udp> Route: <sip: :5060;lr> Content-Type: application/sdp Content-Length: 130 <SDP not shown> 200 OK from MRB to AS SIP/ OK Via: SIP/2.0/UDP :6742;branch=z9hG4bKa-3 P-Charging-Vector: icid-value= @ ;icid-genaddr= ;hop-count=4 From: <sip: @leapstone.com>;tag=hssua_ b To: sip: @leapstone.com;tag=leap-z9hg4bka-3 Call-ID: @ CSeq: 2 INVITE Contact: sip:dialog@ :5060 Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REGISTER,UPDAT E,REFER Content-Type: application/sdp Content-Length: 130 <SDP not shown> ACK from AS to MRB ACK sip:dialog@ :5060 SIP/2.0 Via: SIP/2.0/UDP :6742;branch=z9hG4bKa-3 From: <sip: @leapstone.com>;tag=hssua_ b To: sip: @leapstone.com;tag=leap-z9hg4bka-3 Call-ID: @ CSeq: 2 ACK Contact: <sip:service@ :6742> Max-Forwards: 70 Subject: IVT_AS_Voic _b_ACK-3 Content-Length: MultiService Forum. All Rights Reserved. 17 of 18

18 ACK from MRB to MS ACK sip: :6840 SIP/2.0 Via: SIP/2.0/UDP :5060;branch=z9hG4bK Max-Forwards: 70 From: To: Call-ID: CSeq: 1 ACK Contact: <sip: @ :5060> Content-Length: MultiService Forum. All Rights Reserved. 18 of 18

Implementation Agreement for ISC interface MSF-IA-SIP.013-FINAL

Implementation Agreement for ISC interface MSF-IA-SIP.013-FINAL MSF-IA-SIP.013-FINAL MultiService Forum Implementation Agreement MSF-IA-SIP.013-FINAL Contribution Number: msf2006.004.04 Document Filename: MSF-IA-SIP.013-FINAL Working Group: Protocol and Control Title:

More information

Implementation Agreement for Roaming Between MSF R3 networks MSF-IA-ROAMING.001-FINAL

Implementation Agreement for Roaming Between MSF R3 networks MSF-IA-ROAMING.001-FINAL Implementation Agreement for Roaming Between MSF R3 networks MSF-IA-ROAMING.001-FINAL MultiService Forum Implementation Agreement Contribution Number: msf2006.146.03 Document Filename: MSF-IA-ROAMING.001-FINAL

More information

INTERFACE SPECIFICATION SIP Trunking. 8x8 SIP Trunking. Interface Specification. Version 2.0

INTERFACE SPECIFICATION SIP Trunking. 8x8 SIP Trunking. Interface Specification. Version 2.0 8x8 Interface Specification Version 2.0 Table of Contents Introduction....3 Feature Set....3 SIP Interface....3 Supported Standards....3 Supported SIP methods....4 Additional Supported SIP Headers...4

More information

MSF Architecture for 3GPP Evolved Packet System (EPS) Access MSF-LTE-ARCH-EPS-002.FINAL

MSF Architecture for 3GPP Evolved Packet System (EPS) Access MSF-LTE-ARCH-EPS-002.FINAL MSF Architecture for 3GPP Evolved Packet System (EPS) Access MSF-LTE-ARCH-EPS-002.FINAL MultiService Forum Architecture Agreement Contribution Number: Document Filename: Working Group: Title: Editor: Contact

More information

AMERICAN NATIONAL STANDARD

AMERICAN NATIONAL STANDARD ENGINEERING COMMITTEE Data Standards Subcommittee AMERICAN NATIONAL STANDARD ANSI/SCTE 173-3 2017 Specification for Authentication in Preferential Telecommunications over IPCablecom2 Networks NOTICE The

More information

Technical Committee. Addendum to Security Specification v1.1 In-Band Security for Simplex Connections. af-sec

Technical Committee. Addendum to Security Specification v1.1 In-Band Security for Simplex Connections. af-sec Technical Committee Addendum to Security Specification v1.1 In-Band Security for Simplex Connections July 2002 2001 by The ATM Forum. This specification/document may be reproduced and distributed in whole,

More information

Department of Computer Science. Burapha University 6 SIP (I)

Department of Computer Science. Burapha University 6 SIP (I) Burapha University ก Department of Computer Science 6 SIP (I) Functionalities of SIP Network elements that might be used in the SIP network Structure of Request and Response SIP messages Other important

More information

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions [MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open

More information

SIP Compliance APPENDIX

SIP Compliance APPENDIX APPENDIX E This appendix describes Cisco SIP proxy server (Cisco SPS) compliance with the Internet Engineering Task Force (IETF) definition of Session Initiation Protocol (SIP) as described in the following

More information

The ATM Forum Technical Committee

The ATM Forum Technical Committee The ATM Forum Technical Committee Physical Layer High Density Glass Optical Fiber Connector Annex AF-PHY-0110.000 February, 1999 AF-PHY-0110.000 Physical Layer High Density Glass Optical 1999 by The ATM

More information

WiMAX End-to-End Network Systems Architecture

WiMAX End-to-End Network Systems Architecture WiMAX End-to-End Network Systems Architecture (Stage : Architecture Tenets, Reference Model and Reference Points) [GPP WiMAX Interworking] Authorized Distribution: Public Access subject to stated terms.

More information

SDLC INTELLECTUAL PROPERTY POLICY

SDLC INTELLECTUAL PROPERTY POLICY SDLC INTELLECTUAL PROPERTY POLICY Last Revised: 11/14/17 1. Introduction. This Intellectual Property Policy ( Policy ) governs intellectual property rights of the SDL Consortium ( SDLC ) and its Members

More information

Enabler Test Specification for RCS Conformance

Enabler Test Specification for RCS Conformance Enabler Test Specification for RCS Conformance Candidate Version 1.2.2 10 Mar 2014 Open Mobile Alliance OMA-ETS-RCS-CON-V1_2_2-20140310-C OMA-ETS-RCS-CON-V1_2_2-20140310-C Page 2 (74) Use of this document

More information

Technical Specification MEF 6. Ethernet Services Definitions - Phase I. June 2004

Technical Specification MEF 6. Ethernet Services Definitions - Phase I. June 2004 Technical Specification Ethernet Services Definitions - Phase I June 2004 contain the following statement: "Reproduced with permission of the Metro Ethernet Forum." No user of this document is authorized

More information

ETSI TS V8.2.0 ( ) Technical Specification

ETSI TS V8.2.0 ( ) Technical Specification TS 124 147 V8.2.0 (2009-01) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Conferencing using the IP Multimedia (IM)

More information

3GPP TR V ( )

3GPP TR V ( ) TR 24.930 V10.1.0 (2011-12) Technical Report 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Signalling flows for the session setup in the IP Multimedia core

More information

Reserving N and N+1 Ports with PCP

Reserving N and N+1 Ports with PCP Reserving N and N+1 Ports with PCP draft-boucadair-pcp-rtp-rtcp IETF 83-Paris, March 2012 M. Boucadair and S. Sivakumar 1 Scope Defines a new PCP Option to reserve a pair of ports (N and N+1) in a PCP-controlled

More information

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions

[MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions [MS-TURNBWM]: Traversal using Relay NAT (TURN) Bandwidth Management Extensions Intellectual Property Rights Notice for Open Specifications Documentation Technical Documentation. Microsoft publishes Open

More information

Technical Committee. Addendum to ATM Physical Medium Dependent Interface Specification for 155 Mb/s Over Twisted Pair Cable (af-phy-0015.

Technical Committee. Addendum to ATM Physical Medium Dependent Interface Specification for 155 Mb/s Over Twisted Pair Cable (af-phy-0015. Technical Committee Addendum to ATM Physical Medium Dependent Interface Specification for 155 Mb/s Over Twisted Pair Cable (af-phy-0015.000) af-phy-0053.000 January 1996 af-phy-053.000 ATM Forum Technical

More information

ETSI TS V1.1.1 ( )

ETSI TS V1.1.1 ( ) TS 183 028 V1.1.1 (2006-04) Technical Specification Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); Common basic communication procedures; Protocol specification

More information

EMPLOYER CONTRIBUTION AGREEMENT

EMPLOYER CONTRIBUTION AGREEMENT EMPLOYER CONTRIBUTION AGREEMENT This Employer Contribution Agreement ( Agreement ) is entered into by and between, your successors and assigns ( You ) and Oracle America, Inc. ( Oracle ) as of the date

More information

Frequently Asked Questions (Dialogic BorderNet 500 Gateways)

Frequently Asked Questions (Dialogic BorderNet 500 Gateways) Frequently Asked Questions (Dialogic BorderNet 500 Gateways) Q: What is a Dialogic BorderNet 500 Gateway, and what are its main functions? A: A Dialogic BorderNet 500 Gateway consists of a full featured

More information

draft-ietf-sip-info-method-02.txt February 2000 The SIP INFO Method Status of this Memo

draft-ietf-sip-info-method-02.txt February 2000 The SIP INFO Method Status of this Memo HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 07:53:57 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 15 Feb 2000 17:03:00 GMT ETag: "3239a5-465b-38a986c4" Accept-Ranges: bytes Content-Length: 18011 Connection:

More information

Ecma International Policy on Submission, Inclusion and Licensing of Software

Ecma International Policy on Submission, Inclusion and Licensing of Software Ecma International Policy on Submission, Inclusion and Licensing of Software Experimental TC39 Policy This Ecma International Policy on Submission, Inclusion and Licensing of Software ( Policy ) is being

More information

Request for Comments: 2976 Category: Standards Track October 2000

Request for Comments: 2976 Category: Standards Track October 2000 Network Working Group S. Donovan Request for Comments: 2976 dynamicsoft Category: Standards Track October 2000 Status of this Memo The SIP INFO Method This document specifies an Internet standards track

More information

Information About SIP Compliance with RFC 3261

Information About SIP Compliance with RFC 3261 APPENDIX A Information About SIP Compliance with RFC 3261 This appendix describes how the Cisco SIP IP phone complies with the IETF definition of SIP as described in RFC 3261. It has compliance information

More information

Multiservice Switching Forum Contribution

Multiservice Switching Forum Contribution Multiservice Switching Forum Contribution Contribution Number: msf2010.095.01 Last Saved: 03/26/2013 16:03 A3/P3 Working Group: Interoperability and Test Title: Test Plan for LTE/EPC Interoperability Event

More information

Quality of Service for Next Generation Voice Over IP Networks

Quality of Service for Next Generation Voice Over IP Networks MSF Technical Report Quality of Service for Next Generation Voice Over IP Networks Author: Chris Gallon Company: Fujitsu Contact: c.gallon@ftel.co.uk www.msforum.org February, 2003 ABSTRACT This white

More information

IETF TRUST. Legal Provisions Relating to IETF Documents. February 12, Effective Date: February 15, 2009

IETF TRUST. Legal Provisions Relating to IETF Documents. February 12, Effective Date: February 15, 2009 IETF TRUST Legal Provisions Relating to IETF Documents February 12, 2009 Effective Date: February 15, 2009 1. Background The IETF Trust was formed on December 15, 2005, for, among other things, the purpose

More information

Technical White Paper for NAT Traversal

Technical White Paper for NAT Traversal V300R002 Technical White Paper for NAT Traversal Issue 01 Date 2016-01-15 HUAWEI TECHNOLOGIES CO., LTD. 2016. All rights reserved. No part of this document may be reproduced or transmitted in any form

More information

PacketCable. PacketCable Residential SIP Telephony Accounting Specification PKT-SP-RST-ACCT-C CLOSED. Notice

PacketCable. PacketCable Residential SIP Telephony Accounting Specification PKT-SP-RST-ACCT-C CLOSED. Notice CLOSED Notice This PacketCable specification is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers.

More information

3GPP TR V7.0.0 ( )

3GPP TR V7.0.0 ( ) TR 24.930 V7.0.0 (2006-12) Technical Report 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Signalling flows for the session setup in the IP Multimedia core

More information

Technical Committee. Addendum to BISDN Inter Carrier Interface (B-ICI) Specification, v2.0. (B-ICI Specification, v2.1) af-bici-0068.

Technical Committee. Addendum to BISDN Inter Carrier Interface (B-ICI) Specification, v2.0. (B-ICI Specification, v2.1) af-bici-0068. Technical Committee Addendum to BISDN Inter Carrier Interface (B-ICI) Specification, v2.0 (B-ICI Specification, v2.1) November, 1996 Addendum to B-ICI Specification, v2.0 1996 The ATM Forum. All Rights

More information

MEF Specification. Amendment to MEF 55 - TOSCA Service Templates. Approved Draft 1 July

MEF Specification. Amendment to MEF 55 - TOSCA Service Templates. Approved Draft 1 July 1 2 3 4 Specification 5 6 7 8 9 Amendment to 55 - TOSCA Service Templates 10 11 12 13 14 15 Approved Draft 1 July 13 2017 The Forum 2017. Any reproduction of this document, or any portion thereof, shall

More information

All-IP Core Network Multimedia Domain

All-IP Core Network Multimedia Domain GPP X.S00-00-0 Version.0 Version Date: July 00 0 All-IP Core Network Multimedia Domain IP Multimedia (IMS) session handling; IP Multimedia (IM) Call Model; Stage 0 COPYRIGHT NOTICE GPP and its Organizational

More information

ECLIPSE FOUNDATION, INC. INDIVIDUAL COMMITTER AGREEMENT

ECLIPSE FOUNDATION, INC. INDIVIDUAL COMMITTER AGREEMENT ECLIPSE FOUNDATION, INC. INDIVIDUAL COMMITTER AGREEMENT THIS INDIVIDUAL COMMITTER AGREEMENT (THE AGREEMENT ) is entered into as of the day of, 20 (the Effective Date ) by and between Eclipse Foundation,

More information

ETSI TS V8.7.0 ( ) Technical Specification

ETSI TS V8.7.0 ( ) Technical Specification TS 124 247 V8.7.0 (2011-06) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Messaging service using the IP Multimedia

More information

ETSI TS V ( ) Technical Specification

ETSI TS V ( ) Technical Specification TS 124 606 V10.0.0 (2011-03) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Message Waiting Indication (MWI) using

More information

Dialogic PowerMedia Media Resource Broker (MRB)

Dialogic PowerMedia Media Resource Broker (MRB) Dialogic PowerMedia Media Resource Broker (MRB) Technology Guide September 2017 Rev 2.0 www.dialogic.com Copyright and Legal Notice Copyright 2016-2017 Dialogic Corporation. All Rights Reserved. You may

More information

ETSI TS V ( ) Technical Specification

ETSI TS V ( ) Technical Specification TS 124 628 V10.3.0 (2011-06) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Common Basic Communication procedures

More information

White Paper. SIP Trunking: Deployment Considerations at the Network Edge

White Paper. SIP Trunking: Deployment Considerations at the Network Edge SIP Trunking: Deployment Considerations at the Network Edge at the Network Edge Executive Summary The move to Voice over IP (VoIP) and Fax over IP (FoIP) in the enterprise has, until relatively recently,

More information

LAN Emulation Over ATM Version 1.0 Addendum

LAN Emulation Over ATM Version 1.0 Addendum Technical Committee LAN Emulation Over ATM Version 1.0 Addendum December, 1995 ATM Forum Technical Committee 1 (C) 1995 The ATM Forum. All Rights Reserved. No part of this publication may be reproduced

More information

Technical Specification MEF 1. Ethernet Services Model, Phase November 2003

Technical Specification MEF 1. Ethernet Services Model, Phase November 2003 Technical Specification Ethernet Services Model, Phase 1 10 November 2003 Disclaimer The information in this publication is freely available for reproduction and use by any recipient and is believed to

More information

Technical Specification. Amendment to MEF UNI Resiliency Enhancement. October 2015

Technical Specification. Amendment to MEF UNI Resiliency Enhancement. October 2015 Technical Specification Amendment to 10.3 - UNI Resiliency Enhancement October 2015 Disclaimer The information in this publication is freely available for reproduction and use by any recipient and is believed

More information

IETF TRUST. Legal Provisions Relating to IETF Documents. Approved November 6, Effective Date: November 10, 2008

IETF TRUST. Legal Provisions Relating to IETF Documents. Approved November 6, Effective Date: November 10, 2008 IETF TRUST Legal Provisions Relating to IETF Documents Approved November 6, 2008 Effective Date: November 10, 2008 1. Background The IETF Trust was formed on December 15, 2005, for, among other things,

More information

Technical Specification MEF 14. Abstract Test Suite for Traffic Management Phase 1. November, 2005

Technical Specification MEF 14. Abstract Test Suite for Traffic Management Phase 1. November, 2005 Technical Specification Abstract Test Suite for Traffic Management Phase 1 November, 2005 Disclaimer The information in this publication is freely available for reproduction and use by any recipient and

More information

Recommendations for LXI systems containing devices supporting different versions of IEEE 1588

Recommendations for LXI systems containing devices supporting different versions of IEEE 1588 Recommendations for LXI systems containing devices supporting different versions of IEEE 1588 Revision 1.0 December 15, 2008 Edition Page 1 of 9 Notice of Rights All rights reserved. This document is the

More information

Leveraging Amazon Chime Voice Connector for SIP Trunking. March 2019

Leveraging Amazon Chime Voice Connector for SIP Trunking. March 2019 Leveraging Amazon Chime Voice Connector for SIP Trunking March 2019 Notices Customers are responsible for making their own independent assessment of the information in this document. This document: (a)

More information

Request for Comments: 3959 Category: Standards Track December 2004

Request for Comments: 3959 Category: Standards Track December 2004 Network Working Group G. Camarillo Request for Comments: 3959 Ericsson Category: Standards Track December 2004 Status of This Memo The Early Session Disposition Type for the Session Initiation Protocol

More information

UNCONTROLLED IF PRINTED

UNCONTROLLED IF PRINTED 161Thorn Hill Road Warrendale, PA 15086-7527 1. Scope 2. Definitions PROGRAM DOCUMENT PD 1000 Issue Date: 19-Apr-2015 Revision Date: 26-May-2015 INDUSTRY MANAGED ACCREDITATION PROGRAM DOCUMENT Table of

More information

3GPP TS V ( )

3GPP TS V ( ) TS 24.238 V11.2.0 (2013-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Session Initiation Protocol (SIP) based user configuration;

More information

Journal of Information, Control and Management Systems, Vol. X, (200X), No.X SIP OVER NAT. Pavel Segeč

Journal of Information, Control and Management Systems, Vol. X, (200X), No.X SIP OVER NAT. Pavel Segeč SIP OVER NAT Pavel Segeč University of Žilina, Faculty of Management Science and Informatics, Slovak Republic e-mail: Pavel.Segec@fri.uniza.sk Abstract Session Initiation Protocol is one of key IP communication

More information

NICC ND 1635 V 1.1.1( )

NICC ND 1635 V 1.1.1( ) ND 1635 V 1.1.1(2008-06) Document NGN Interconnect: Media Path Technical Specification Network Interoperability Consultative Committee, Ofcom, 2a Southwark Bridge Road, London, SE1 9HA. 2 ND 1635 V 1.1.1(2008-06)

More information

Internet Engineering Task Force (IETF) S. McGlashan Hewlett-Packard May Media Control Channel Framework. Abstract

Internet Engineering Task Force (IETF) S. McGlashan Hewlett-Packard May Media Control Channel Framework. Abstract Internet Engineering Task Force (IETF) Request for Comments: 6230 Category: Standards Track ISSN: 2070-1721 C. Boulton NS-Technologies T. Melanchuk Rainwillow S. McGlashan Hewlett-Packard May 2011 Media

More information

FIPA ACL Message Structure Specification

FIPA ACL Message Structure Specification 1 2 3 4 5 FOUNDATION FOR INTELLIGENT PHYSICAL AGENTS FIPA ACL Message Structure Specification 6 7 Document title FIPA ACL Message Structure Specification Document number XC00061E Document source FIPA TC

More information

Technical Specification MEF 13. User Network Interface (UNI) Type 1 Implementation Agreement. November, 2005

Technical Specification MEF 13. User Network Interface (UNI) Type 1 Implementation Agreement. November, 2005 Technical Specification User Network Interface (UNI) Type 1 Implementation Agreement November, 2005 Disclaimer The information in this publication is freely available for reproduction and use by any recipient

More information

Application Notes for Configuring SIP Trunking between Bandwidth.com SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1.

Application Notes for Configuring SIP Trunking between Bandwidth.com SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1. Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between Bandwidth.com SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1.0 Abstract These

More information

BT SIP Trunk Configuration Guide

BT SIP Trunk Configuration Guide CUCM 9.1 BT SIP Trunk Configuration Guide This document covers service specific configuration required for interoperability with the BT SIP Trunk service. Anything which could be considered as normal CUCM

More information

ETSI TS V7.4.0 ( )

ETSI TS V7.4.0 ( ) TS 124 279 V7.4.0 (2007-03) Technical Specification Universal Mobile Telecommunications System (UMTS); Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services; Stage 3 (3GPP TS 24.279

More information

Technical Committee. ATM User-Network Interface (UNI) Specification Version 4.1

Technical Committee. ATM User-Network Interface (UNI) Specification Version 4.1 Technical Committee ATM User-Network Interface (UNI) Specification Version 4.1 af-arch-0193.000 November 2002 2002 by The ATM Forum. The ATM Forum hereby grants its members the limited right to reproduce

More information

INCLUDING MEDICAL ADVICE DISCLAIMER

INCLUDING MEDICAL ADVICE DISCLAIMER Jordan s Guardian Angels Terms and Conditions of Use INCLUDING MEDICAL ADVICE DISCLAIMER Your use of this website and its content constitutes your agreement to be bound by these terms and conditions of

More information

Abstract. Avaya Solution & Interoperability Test Lab

Abstract. Avaya Solution & Interoperability Test Lab Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between the PAETEC Broadsoft based SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue 1.0 Abstract

More information

Polycom Video Border Proxy (VBP ) 7301

Polycom Video Border Proxy (VBP ) 7301 RELEASE NOTES 14.8.2 January 2017 3725-78311-001I Polycom Video Border Proxy (VBP ) 7301 Release Notes Polycom VBP 7301 Version 14 Current Version: 14.8.2 Release Date: January 2017 Polycom VBP Release

More information

ETSI TR V (201

ETSI TR V (201 TR 124 930 V13.0.0 (201 16-01) TECHNICAL REPORT Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Signalling flows for the session setup in

More information

SERVICES and MICROSOFT HOSTED EXCHANGE

SERVICES and MICROSOFT HOSTED EXCHANGE EMAIL SERVICES and MICROSOFT HOSTED EXCHANGE 1. Description of Service. Web.com may provide you with the capability of sending and receiving electronic mail via the Internet and through mobile phones ("Email

More information

Technical Committee. E1 Physical Interface Specification. af-phy

Technical Committee. E1 Physical Interface Specification. af-phy Technical Committee E1 Physical Interface Specification September 1996 E1 Physical Interface Specification 1996 The ATM Forum. All Rights Reserved. No part of this publication may be reproduced in any

More information

Tech-invite. RFC 3261's SIP Examples. biloxi.com Registrar. Bob's SIP phone

Tech-invite. RFC 3261's SIP Examples. biloxi.com Registrar. Bob's SIP phone Tech-invite http://www.tech-invite.com RFC 3261's SIP Examples V2.2 November 22, 2005 Registrar Bob's SIP INVITE 100 Trying Proxy INVITE 100 Trying Proxy 200 OK INVITE REGISTER This is a representation,

More information

Oracle Communications WebRTC Session Controller

Oracle Communications WebRTC Session Controller Oracle Communications WebRTC Session Controller Concepts Release 7.0 E40976-01 November 2013 Oracle Communications WebRTC Session Controller Concepts, Release 7.0 E40976-01 Copyright 2013, Oracle and/or

More information

TCG Physical Security Interoperability Alliance IP Video Use Case 002 (PSI-UC-IPV002) Specification Version 1.0 Revision 0.2

TCG Physical Security Interoperability Alliance IP Video Use Case 002 (PSI-UC-IPV002) Specification Version 1.0 Revision 0.2 TCG Physical Security Interoperability Alliance IP Video Use Case 002 (PSI-UC-IPV002) Specification Version 1.0 Revision 0.2 Revision History Description Date By Version 1.0 Rev 0.1 Initial Draft August

More information

Cisco Expressway with Jabber Guest

Cisco Expressway with Jabber Guest Cisco Expressway with Jabber Guest Deployment Guide First Published: Decemeber 2016 Cisco Expressway X8.9 Cisco Jabber Guest Server 10.6.9 (or later) Cisco Systems, Inc. www.cisco.com Contents Preface

More information

Technical Specification MEF 27. Abstract Test Suite For. May 20 th, 2010

Technical Specification MEF 27. Abstract Test Suite For. May 20 th, 2010 Technical Specification Abstract Test Suite For UNI Type 2 Part 5: Enhanced UNI Attributes & Part 6: L2CP Handling May 20 th, 2010 of the information contained herein. Page 1 Disclaimer The information

More information

Abstract. Avaya Solution & Interoperability Test Lab

Abstract. Avaya Solution & Interoperability Test Lab Avaya Solution & Interoperability Test Lab Application Notes for Configuring SIP Trunking between Sotel IP Services SIP Edge Advanced SIP Trunking Solution and an Avaya IP Office Telephony Solution Issue

More information

Overview of SIP. Information About SIP. SIP Capabilities. This chapter provides an overview of the Session Initiation Protocol (SIP).

Overview of SIP. Information About SIP. SIP Capabilities. This chapter provides an overview of the Session Initiation Protocol (SIP). This chapter provides an overview of the Session Initiation Protocol (SIP). Information About SIP, page 1 How SIP Works, page 4 How SIP Works with a Proxy Server, page 5 How SIP Works with a Redirect Server,

More information

Dialogic Brooktrout SR140 Fax Software with babytel SIP Trunking Service

Dialogic Brooktrout SR140 Fax Software with babytel SIP Trunking Service Dialogic Brooktrout SR140 Fax Software with babytel SIP Trunking Service March 2011 64-0600-27 www.dialogic.com Copyright and Legal Notice Copyright 2011 Dialogic Inc. All Rights Reserved. You may not

More information

Fusion360: Static SIP Trunk Programming Guide

Fusion360: Static SIP Trunk Programming Guide Fusion360: Static SIP Trunk Programming Guide Contents: SIP Trunk Programming Guide.................................................................................. 4 Step 1: Gather the Following Information

More information

Entrust SSL Web Server Certificate Subscription Agreement

Entrust SSL Web Server Certificate Subscription Agreement Entrust SSL Web Server Certificate Subscription Agreement ATTENTION - READ CAREFULLY: THIS SUBSCRIPTION AGREEMENT (THIS "AGREEMENT") IS A LEGAL CONTRACT BETWEEN THE PERSON, ENTITY, OR ORGANIZATION NAMED

More information

3GPP TS V8.7.0 ( )

3GPP TS V8.7.0 ( ) TS 23.237 V8.7.0 (2010-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS) Service Continuity; Stage

More information

Client Side Content Screening Framework Architecture

Client Side Content Screening Framework Architecture Client Side Content Screening Framework Architecture Approved Version 1.0 14 Jun 2007 Open Mobile Alliance OMA-AD-Client_Side_CS_FW-V1_0-20070614-A OMA-AD-Client_Side_CS_FW-V1_0-20070614-A Page 2 (14)

More information

S Postgraduate Course in Radio Communications. Application Layer Mobility in WLAN. Antti Keurulainen,

S Postgraduate Course in Radio Communications. Application Layer Mobility in WLAN. Antti Keurulainen, S-72.333 Postgraduate Course in Radio Communications. Application Layer Mobility in Antti Keurulainen, 13.5.2004 antti.keurulainen@bitville.fi The Mobility Concepts is Link layer Mobility Network layer

More information

3GPP TS V ( )

3GPP TS V ( ) 3GPP TS 24.379 V13.1.1 (2016-06) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Networks and Terminals; Mission Critical Push To Talk (MCPTT) call control;

More information

Enabler Release Definition for Smartcard-Web-Server

Enabler Release Definition for Smartcard-Web-Server Enabler Release Definition for Smartcard-Web-Server Candidate Version 1.0 09 Feb 2007 Open Mobile Alliance OMA-ERELD-Smartcard_Web_Server-V1_0-20070209-C OMA-ERELD-Smartcard_Web_Server-V1_0-20070209-C

More information

System Architecture Model Version 1.1 WV Tracking Number: WV-020

System Architecture Model Version 1.1 WV Tracking Number: WV-020 System Architecture Model Version 1.1 WV Tracking Number: WV-020 Notice Copyright 2001-2002 Ericsson, Motorola and Nokia. All Rights Reserved. Implementation of all or part of any Specification may require

More information

Site Impact Policies for Website Use

Site Impact Policies for Website Use Site Impact Policies for Website Use Thank you for visiting the Site Impact website (the Website ). We have set up some ground rules to ensure protection of our rights and yours. Site Impact reserves the

More information

Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol

Authentication, Authorization and Accounting Requirements for the Session Initiation Protocol Internet Engineering Task Force INTERNET-DRAFT draft-ietf-sipping-aaa-req-02.ps SIP WG J. Loughney, G. Camarillo Nokia, Ericsson February 5, 2003 Expires: August, 2003 Authentication, Authorization and

More information

ITU-T Q Signalling architecture and requirements for IP-based short message service over ITU-T defined NGN

ITU-T Q Signalling architecture and requirements for IP-based short message service over ITU-T defined NGN I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T Q.3053 TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2017) SERIES Q: SWITCHING AND SIGNALLING, AND ASSOCIATED MEASUREMENTS

More information

Compliance with RFC 3261

Compliance with RFC 3261 APPENDIX A Compliance with RFC 3261 This appendix describes how the Cisco Unified IP Phone 7960G and 7940G complies with the IETF definition of SIP as described in RFC 3261. It contains compliance information

More information

Internet Engineering Task Force (IETF) Request for Comments: 7403 Category: Standards Track November 2014 ISSN:

Internet Engineering Task Force (IETF) Request for Comments: 7403 Category: Standards Track November 2014 ISSN: Internet Engineering Task Force (IETF) H. Kaplan Request for Comments: 7403 Oracle Category: Standards Track November 2014 ISSN: 2070-1721 Abstract A Media-Based Traceroute Function for the Session Initiation

More information

Schedule Identity Services

Schedule Identity Services This document (this Schedule") is the Schedule for Services related to the identity management ( Identity Services ) made pursuant to the ehealth Ontario Services Agreement (the Agreement ) between ehealth

More information

You may use the Service to either access, establish or change the following:

You may use the Service to either access, establish or change the following: Online Access Agreement June 18, 2015 (Revision date) I. Introduction This Online Access Agreement (this "Agreement") contains the terms that govern your use of the Participants' Private Area of the www.afmsagaftrafund.org

More information

ETSI TS V ( )

ETSI TS V ( ) TS 124 147 V15.0.0 (2018-06) TECHNICAL SPECIFICATION Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; Conferencing using the IP Multimedia

More information

ATIS PROCEDURES FOR CHANGE IN E.164 COUNTRY CODE ASSIGNMENTS

ATIS PROCEDURES FOR CHANGE IN E.164 COUNTRY CODE ASSIGNMENTS ATIS-0300054 PROCEDURES FOR CHANGE IN E.164 COUNTRY CODE ASSIGNMENTS September 5, 2014 Copyright 2014 by the Alliance for Telecommunications Industry Solutions, Inc. All rights reserved. The Procedures

More information

Request for Comments: 5369 Category: Informational October Framework for Transcoding with the Session Initiation Protocol (SIP)

Request for Comments: 5369 Category: Informational October Framework for Transcoding with the Session Initiation Protocol (SIP) Network Working Group G. Camarillo Request for Comments: 5369 Ericsson Category: Informational October 2008 Framework for Transcoding with the Session Initiation Protocol (SIP) Status of This Memo This

More information

Z.com Hosting Service Order

Z.com Hosting Service Order 1 Z.com Hosting Service Order This Z.com Hosting Service Order (hereinafter referred to as the Order ) is an integral part of the Master Service Agreement (hereinafter referred to as the Agreement or MSA

More information

ETSI TS V ( )

ETSI TS V ( ) TS 124 629 V11.3.0 (2014-01) Technical Specification Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Explicit Communication Transfer (ECT)

More information

PacketCable 2.0. HSS Technical Report PKT-TR-HSS-V RELEASED. Notice

PacketCable 2.0. HSS Technical Report PKT-TR-HSS-V RELEASED. Notice PacketCable 2.0 HSS Technical Report RELEASED Notice This PacketCable technical report is the result of a cooperative effort undertaken at the direction of Cable Television Laboratories, Inc. for the benefit

More information

OIX DDP. Open-IX Document Development Process draft July 2017

OIX DDP. Open-IX Document Development Process draft July 2017 OIX DDP Open-IX Document Development Process draft 04 11 July 2017 Table 1 - Version History Version Date Author Description d01 7 May 2017 Chris Grundemann Initial Draft d02 21 May 2017 Chris Grundemann

More information

OCTOSHAPE SDK AND CLIENT LICENSE AGREEMENT (SCLA)

OCTOSHAPE SDK AND CLIENT LICENSE AGREEMENT (SCLA) OCTOSHAPE SDK AND CLIENT LICENSE AGREEMENT (SCLA) This is a License Agreement (the "Agreement") for certain code (the Software ) owned by Akamai Technologies, Inc. ( Akamai ) that is useful in connection

More information

Request for Comments: 4083 Category: Informational May 2005

Request for Comments: 4083 Category: Informational May 2005 Network Working Group M. Garcia-Martin Request for Comments: 4083 Nokia Category: Informational May 2005 Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation

More information

3GPP TS V7.2.0 ( )

3GPP TS V7.2.0 ( ) TS 24.341 V7.2.0 (2007-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Support of SMS over IP networks; Stage 3 (Release 7) GLOBAL

More information

Session Initiation Protocol (SIP)

Session Initiation Protocol (SIP) Session Initiation Protocol (SIP) Introduction A powerful alternative to H.323 More flexible, simpler Easier to implement Advanced features Better suited to the support of intelligent user devices A part

More information