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

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

MultiService Forum Implementation Agreement Contribution Number: msf2005.128.03 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 swalker@leapstone.com IM leapstone_stuart@msn.com Working Group Chairperson: Chris Gallon (c.gallon@ftel.co.uk) 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 http://www.msforum.org/ 2006 MultiService Forum. All Rights Reserved. 2 of 18

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 39355 California Street, Suite 307 Fremont, CA 94538 USA Phone: +1 510 608-5922 Fax: +1 510 608-5917 info@msforum.org http://www.msforum.org 2006 MultiService Forum. All Rights Reserved. 3 of 18

Contents 1 MSF... 5 2 Applicability and Scope... 5 2.1 Differences from MSF Release 2... 6 2.2 Modes of Operation... 6 3 MSF Client to Media Resource Broker SIP Interface... 9 3.1 INVOKING the Media Resource Broker... 9 3.1.1 SIP Header Usage... 9 3.1.2 Media Resource Broker Responses... 11 3.2 Considerations for Applications using 3 rd Party Call Control... 12 4 NAT and Firewall traversal... 13 5 QoS aspects... 13 5.1 Alternate configuration... 13 6 Security aspects... 14 7 Redundancy and resilience... 14 8 References... 14 9 Acknowledgements... 14 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... 12 Figure 7 - Alternate configuration for QoS resource management... 13 2006 MultiService Forum. All Rights Reserved. 4 of 18

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. 2006 MultiService Forum. All Rights Reserved. 5 of 18

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. 2006 MultiService Forum. All Rights Reserved. 6 of 18

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

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. 2006 MultiService Forum. All Rights Reserved. 8 of 18

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. 3.1.1 SIP Header Usage The following sections indicate the expected usage of specific SIP Headers in the INVITE sent to the Media Resource Broker. 3.1.1.1 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. 2006 MultiService Forum. All Rights Reserved. 9 of 18

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. 3.1.1.2 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. 3.1.1.3 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. 3.1.1.4 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 3. 3.1.1.5 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. 3.1.1.6 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. 3.1.1.7 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. 2006 MultiService Forum. All Rights Reserved. 10 of 18

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. 3.1.2.1 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. 3.1.2.2 480 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. 3.1.2.3 488 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. 3.1.2.4 302 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. 2006 MultiService Forum. All Rights Reserved. 11 of 18

Figure 5 - Media Resource Broker overflow model 3.1.2.5 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. 2006 MultiService Forum. All Rights Reserved. 12 of 18

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. 2006 MultiService Forum. All Rights Reserved. 13 of 18

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 99.999% 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. 2006 MultiService Forum. All Rights Reserved. 14 of 18

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 10.10.34.39 MRB 10.17.25.2 MS 10.10.24.25 (logical media server id = MR05) INVITE from AS to MRB INVITE sip:dialog@10.17.25.2:5060;br-mrid=mr05 SIP/2.0 P-Charging-Vector: icid-value=1-11517@10.10.34.39;icid-genaddr=10.17.25.2;hop-count=3 Via: SIP/2.0/UDP 10.10.34.39:6742;branch=z9hG4bKa-3 From: <sip:3331230001@leapstone.com>;tag=hssua_2636688448-305b To: sip:3331230003@leapstone.com Call-ID: 1-7-1604807862@10.10.34.39 CSeq: 2 INVITE Contact: <sip:vm@10.10.34.39:6742> Route: <sip:10.17.25.2:5060;lr> Subject: IVT_AS_Voicemail_b_INVITE-3 Max-Forwards: 70 Content-Type: application/sdp P-Asserted-Identity: <sip:3331230001@leapstone.com> Content-Length: 130 <SDP not shown> 100 Trying from MRB to AS SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.10.34.39:6742;branch=z9hG4bKa-3 From: <sip:3331230001@leapstone.com>;tag=hssua_2636688448-305b To: sip:3331230003@leapstone.com;tag=leap-z9hg4bka-3 Call-ID: 1-7-1604807862@10.10.34.39 CSeq: 2 INVITE Contact: sip:dialog@10.17.25.2:5060 Content-Length: 0 INVITE from MRB to MS INVITE sip:dialog@10.10.24.25:6840 SIP/2.0 Via: SIP/2.0/UDP 10.17.25.2:5060;branch=z9hG4bK2660688448-55886 Max-Forwards: 70 2006 MultiService Forum. All Rights Reserved. 15 of 18

Subject: IVT_AS_Voicemail_b_INVITE-3 P-Asserted-Identity: <sip:3331230001@leapstone.com> P-Charging-Vector: icid-value=1-11517@10.10.34.39;icid-genaddr=10.17.25.2;hop-count=4 Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,OPTIONS,SUBSCRIBE,NOTIFY,REGISTER,UPDAT E,REFER From: <sip:3331230001@leapstone.com>;tag=hssua_2637688448--59328 To: sip:3331230003@leapstone.com Call-ID: 8--2129519997@10.17.25.2 CSeq: 1 INVITE Contact: <sip:3331230001@10.17.25.2:5060> Content-Type: application/sdp Content-Length: 130 <SDP not shown> 100 Trying from MS to MRB SIP/2.0 100 Trying Via: SIP/2.0/UDP 10.17.25.2:5060;branch=z9hG4bK2660688448-55886 From: <sip:3331230001@leapstone.com>;tag=hssua_2637688448--59328 To: sip:3331230003@leapstone.com Call-ID: 8--2129519997@10.17.25.2 CSeq: 1 INVITE Contact: <sip:10.10.24.25:6840;transport=udp> Route: <sip:10.17.25.2:5060;lr> Content-Length: 0 2006 MultiService Forum. All Rights Reserved. 16 of 18

200 OK from MS to MRB SIP/2.0 200 OK P-Charging-Vector: icid-value=1-11517@10.10.34.39;icid-genaddr=10.17.25.2;hop-count=4 Via: SIP/2.0/UDP 10.17.25.2:5060;branch=z9hG4bK2660688448-55886 From: <sip:3331230001@leapstone.com>;tag=hssua_2637688448--59328 To: sip:3331230003@leapstone.com Call-ID: 8--2129519997@10.17.25.2 CSeq: 1 INVITE Contact: <sip:10.10.24.25:6840;transport=udp> Route: <sip:10.17.25.2:5060;lr> Content-Type: application/sdp Content-Length: 130 <SDP not shown> 200 OK from MRB to AS SIP/2.0 200 OK Via: SIP/2.0/UDP 10.10.34.39:6742;branch=z9hG4bKa-3 P-Charging-Vector: icid-value=1-11517@10.10.34.39;icid-genaddr=10.17.25.2;hop-count=4 From: <sip:3331230001@leapstone.com>;tag=hssua_2636688448-305b To: sip:3331230003@leapstone.com;tag=leap-z9hg4bka-3 Call-ID: 1-7-1604807862@10.10.34.39 CSeq: 2 INVITE Contact: sip:dialog@10.17.25.2: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@10.17.25.2:5060 SIP/2.0 Via: SIP/2.0/UDP 10.10.34.39:6742;branch=z9hG4bKa-3 From: <sip:3331230001@leapstone.com>;tag=hssua_2636688448-305b To: sip:3331230003@leapstone.com;tag=leap-z9hg4bka-3 Call-ID: 1-7-1604807862@10.10.34.39 CSeq: 2 ACK Contact: <sip:service@10.10.34.39:6742> Max-Forwards: 70 Subject: IVT_AS_Voicemail_b_ACK-3 Content-Length: 0 2006 MultiService Forum. All Rights Reserved. 17 of 18

ACK from MRB to MS ACK sip:10.10.24.25:6840 SIP/2.0 Via: SIP/2.0/UDP 10.17.25.2:5060;branch=z9hG4bK2664688448-23585 Max-Forwards: 70 From: <sip:3331230001@leapstone.com>;tag=hssua_2637688448--59328 To: sip:3331230003@leapstone.com Call-ID: 8--2129519997@10.17.25.2 CSeq: 1 ACK Contact: <sip:3331230001@10.17.25.2:5060> Content-Length: 0 2006 MultiService Forum. All Rights Reserved. 18 of 18