Msrp rfc pdf

The required number of labels required for the protection paths The RPS protocol uses ring tunnels, and each tunnel has a set of labels. The number of ring tunnel labels is related to the number of ring nodes and is independent of the number of protected LSPs. For detailed information, see Section 4. The amount of control and management-plane transactions Each ring node requires only one instance of the RPS protocol per ring.

This means that only one maintenance operation is required per ring node. Minimize the signaling and routing information exchange during protection Information exchange during a protection switch is using the in-band RPS and OAM messages. No control-plane interactions are required. Shared-Ring Protection Architecture 4. As shown in Figure 1, the new logical layer consists of ring tunnels that provide a server layer for the LSPs traversing the ring. Once a ring tunnel is established, the forwarding and protection switching of the ring are all performed at the ring tunnel level.

A port can carry multiple ring tunnels, and a ring tunnel can carry multiple LSPs. Establishment of the Ring Tunnel The Ring tunnels are established based on the egress nodes. The egress node is the node where traffic leaves the ring. LSPs that have the same egress node on the ring and travel along the ring in the same direction clockwise or anticlockwise share the same ring tunnels.

In other words, all the LSPs that traverse the ring in the same direction and exit from the same node share the same working ring tunnel and protection ring tunnel. For each egress node, four ring tunnels are established: o one clockwise working ring tunnel, which is protected by the anticlockwise protection ring tunnel o one anticlockwise protection ring tunnel o one anticlockwise working ring tunnel, which is protected by the clockwise protection ring tunnel o one clockwise protection ring tunnel The structure of the protection tunnels is determined by the selected protection mechanism.

This will be detailed in subsequent sections. A similar provisioning should be applied for any other node on the ring. The ring tunnel labels on each hop of the ring tunnel can be either configured statically, provisioned by a controller, or distributed dynamically via a control protocol.

For an LSP that traverses the ring tunnel, the ingress ring node and the egress ring node are considered adjacent at the LSP layer, and LSP label needs to be allocated at these two ring nodes. The control plane for label distribution is outside the scope of this document. The transit nodes on the working ring tunnel swap the ring tunnel labels and forward the packets to the next hop.

When the packet arrives at the egress node, the egress node pops the ring tunnel label and forwards the packets based on the inner LSP label Cheng, et al.

Transit nodes: In this case, Nodes B and C forward the packets by swapping the working ring tunnel labels. Egress node: When the packet arrives at Node D i.

Protection switching is triggered by the failure detected on the ring by the OAM mechanisms. A node failure is regarded as the failure of two links attached to that node. The two nodes adjacent to the failed node detect the failure in the links that are connected to the failed node. Ring Protection This section specifies the ring protection mechanisms in detail. In general, the description uses the clockwise working ring tunnel and the corresponding anticlockwise protection ring tunnel as an example, but the mechanism is applicable in the same way to the anticlockwise working and clockwise protection ring tunnels.

In a ring network, each working ring tunnel is associated with a protection ring tunnel in the opposite direction, and every node MUST obtain the ring topology either by configuration or via a topology discovery mechanism. The ring topology and the connectivity Intact or Severed between two adjacent ring nodes form the ring map. Each ring node maintains the ring map and uses it to perform ring protection switching. Three typical ring protection mechanisms are described in this section: wrapping, short-wrapping, and steering.

All nodes on the same ring MUST use the same protection mechanism. If the RPS protocol in any node detects an RPS message with a protection- switching mode that was not provisioned in that node, a failure of protocol will be reported, and the protection mechanism will not be activated. Wrapping ring protection: the node that detects a failure or accepts a switch request switches the traffic impacted by the failure or the switch request to the opposite direction away from the failure.

In Cheng, et al. Standards Track [Page 11] RFC MSRP Protection Mechanism for Ring Topology August this way, the impacted traffic is switched to the protection ring tunnel by the switching node upstream of the failure, then it travels around the ring to the switching node downstream of the failure through the protection ring tunnel, where it is switched back onto the working ring tunnel to reach the egress node.

Short-wrapping ring protection provides some optimization to wrapping protection, in which the impacted traffic is only switched once to the protection ring tunnel by the switching node upstream to the failure.

At the egress node, the traffic leaves the ring from the protection ring tunnel. This can reduce the traffic detour of wrapping protection. Steering ring protection implies that the node that detects a failure sends a request along the ring to the other node adjacent to the failure, and all nodes in the ring process this information. For the impacted traffic, the ingress node which adds traffic to the ring performs switching of the traffic from working to the protection ring tunnel, and the egress node will drop the traffic received from the protection ring tunnel.

The following sections describe these protection mechanisms in detail. Wrapping With the wrapping mechanism, the protection ring tunnel is a closed ring identified by the egress node.

As specified in the following sections, the closed ring protection tunnel can protect both link failures and node failures. Wrapping can be applicable for the protection of Point-to-Multipoint P2MP LSPs on the ring; the details of which are outside the scope of this document. Wrapping for Link Failure When a link failure between Nodes B and C occurs, if it is a bidirectional failure, both Nodes B and C can detect the failure via the OAM mechanism; if it is a unidirectional failure, one of the two nodes would detect the failure via the OAM mechanism.

In both cases, the node at the other side of the detected failure will be determined by the ring map and informed using the RPS protocol, which is specified in Section 5. The Cheng, et al. The node at the other side of the failed node will be determined by the ring map and informed using the RPS protocol specified in Section 5. The ingress node will update its ring map according to received RPS messages and determine that the egress node is not reachable; thus, it will not send traffic to either the working or the protection tunnel.

Short-Wrapping With the wrapping protection scheme, protection switching is executed at both nodes adjacent to the failure; consequently, the traffic will be wrapped twice.

This mechanism will cause additional latency and bandwidth consumption when traffic is switched to the protection path. Standards Track [Page 14] RFC MSRP Protection Mechanism for Ring Topology August With short-wrapping protection, protection switching is executed only at the node upstream to the failure, and the packet leaves the ring in the protection ring tunnel at the egress node.

This scheme can reduce the additional latency and bandwidth consumption when traffic is switched to the protection path. However, the two directions of a protected bidirectional LSP are no longer co-routed under the protection-switching conditions.

In the traditional wrapping solution, the protection ring tunnel is configured as a closed ring, while in the short-wrapping solution, the protection ring tunnel is configured as ended at the egress node, which is similar to the working ring tunnel. Short-wrapping is easy to implement in shared-ring protection because both the working and protection ring tunnels are terminated on the egress nodes.

Figure 7 shows the clockwise working ring tunnel and the anticlockwise protection ring tunnel with Node D as the egress node. The difference with wrapping occurs in the protection ring tunnel at the egress node. The protection switch at Node D is based on the information from its ring map and the information received via the RPS protocol.

Short-Wrapping for Node Failure For the node failure that happens on a non-egress node, the short- wrapping protection switching is similar to the link failure case as described in the previous section. This section specifies the scenario of an egress node failure. With the short-wrapping mechanism, protection switching can only be performed once from the working ring tunnel to the protection ring tunnel; thus, Node E MUST NOT switch the traffic that is already carried on the protection ring tunnel back to the working Cheng, et al.

This can avoid the temporary traffic loop when the failure happens on the egress node of the ring tunnel. This also illustrates one of the benefits of having separate working and protection ring tunnels in each ring direction. Steering With the steering protection mechanism, the ingress node which adds traffic to the ring performs switching from the working to the protection ring tunnel, and at the egress node, the traffic leaves the ring from the protection ring tunnel.

When a failure occurs in the ring, the node that detects the failure with an OAM mechanism sends the failure information in the opposite direction of the failure hop by hop along the ring using an RPS request message and the ring-map information.

When a ring node receives the RPS message that identifies a failure, it can determine the location of the fault by using the topology information of the ring map and updating the ring map accordingly; then, it can determine whether the LSPs entering the ring locally need to switch over or not. For LSPs that need to switch over, it will switch the LSPs from the working ring tunnels to their corresponding protection ring tunnels.

In the direction that is opposite to the failure position, Node D will send the state report message to Node E, informing Node E of the fault between C and D, and E will update the link state of its ring topology accordingly, changing the link between C and D from normal to fault.

In this way, the state report message is sent hop by hop in the clockwise direction. Similar to Node D, Node C will send the failure information in the anticlockwise direction. The same procedure also applies to the operation of LSP2. Assume the link between Nodes A and B breaks down, as shown in Figure Similar to the above failure case, Node B will detect a fault in the link between A and B, and it will update its ring map, changing the link state between A and B from normal to fault.

The state report message is sent hop by hop in the clockwise direction, notifying every node that there is a fault between Nodes A and B, and every node updates the link state of its ring topology. As a result, Node A will detect a fault in the working ring tunnel to Node D, and switch LSP1 to the protection ring tunnel, while Node B determines that the working ring tunnel for LSP2 still works fine, and it will not perform the switchover. Steering for Node Failure For a node failure that happens on a non-egress node, steering protection switching is similar to the link failure case as described in the previous section.

If the failure occurs at the egress node of the LSP, the ingress node will update its ring map according to the received RPS messages; it will also determine that the egress node is not reachable after the failure, thus it will not send traffic to either the working or the protection tunnel, and a traffic loop can be avoided.

Interconnected Ring Protection 4. For a given ring, the interconnection node acts as the egress node for that ring, meaning that all LSPs using the interconnection node as an egress from one specific ring to another will use the same group of ring tunnels within the ring. This document will discuss two typical interconnected ring topologies: 1.

Single-node interconnected rings In single-node interconnected rings, the connection between the two rings is through a single node. Because the interconnection node is in fact a single point of failure, this topology should be avoided in real transport networks. Figure 11 shows the topology of single-node interconnected rings. Node C is the interconnection node between Ring1 and Ring2. This is not necessarily the same person that created the conference announcement.

Note that the previous version of SDP specified that either an email field or a phone field MUST be specified, but this was widely ignored. The change brings the specification into line with common usage. If an email address or phone number is present, it MUST be specified before the first media field. More than one email or phone field can be given for a session description. Spaces and hyphens may be used to split up a phone field to aid readability if desired.

This MUST be enclosed in parentheses if it is present. If the session is not multicast, then the connection address contains the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields. It is not expected that unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited.

The TTL and the address together define the scope with which multicast packets sent in this conference will be sent. The TTL for the session is appended to the address using a slash as a separator. It is expected that IPv6 scoped addresses will be used to limit the scope of conferences. Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. The receiver can choose the desired quality and hence bandwidth by only subscribing to a subset of these layers.

Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning. This technique keeps unwanted traffic from sites only requiring certain levels of the hierarchy. The primary purpose of this is to give an approximate idea as to whether two or more sessions can coexist simultaneously.

AS The bandwidth is interpreted to be application specific it will be the application's concept of maximum bandwidth. Normally, this will coincide with what is set on the application's "maximum bandwidth" control if applicable.

Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending simultaneously.

This is intended for experimental purposes only. Modifiers MUST be alphanumeric and, although no length limit is given, it is recommended that they be short.

The first and second sub-fields give the start and stop times, respectively, for the session. To convert these values to UNIX time, subtract decimal NTP timestamps are elsewhere represented by bit values, which wrap sometime in the year User interfaces SHOULD strongly discourage the creation of unbounded and permanent sessions as they give no information about when the session is actually going to terminate, and so make scheduling difficult.

The general assumption may be made, when displaying unbounded sessions that have not timed out to the user, that an unbounded session will only be active until half an hour from the current time Handley, et al. If behaviour other than this is required, an end-time SHOULD be given and modified as appropriate when new information becomes available about when the session should really end. Permanent sessions may be shown to the user as never being active unless there are associated repeat times that state precisely when the session will be active.

The syntax for these is a number immediately followed by a single case-sensitive character. Fractional units are not allowed -- a smaller unit should be used instead. To schedule a repeated session that spans a change from daylight saving time to standard time or vice versa, it is necessary to specify offsets from the base time.

This is required because different time zones change time at different times of day, different countries change to or from daylight saving time on different dates, and some countries do not have daylight saving time at all. Thus, in order to schedule a session that is at the same time winter and summer, it must be possible to specify unambiguously by whose time zone a session is scheduled.

To simplify this task for receivers, we allow the sender to specify the NTP time that a time zone adjustment happens and the offset from the time when the session was first scheduled. Adjustments are always relative to the specified start time -- they are not cumulative.

If a session is likely to last several years, it is expected that the session announcement will be modified periodically rather than transmit several years' worth of adjustments in one session announcement. Work is in progress to define new key exchange mechanisms for use with SDP [ 27 ] [ 28 ], and it is expected that new applications will use those mechanisms.

Standards Track [Page 19] RFC SDP July A key field is permitted before the first media entry in which case it applies to all media in the session , or for each media entry as required. The format of keys and their usage are outside the scope of this document, and the key field provides no way to indicate the encryption algorithm to be used, key type, or other information about the key: this is assumed to be provided by the higher-level protocol using SDP.

Many security protocols require two keys: one for confidentiality, another for integrity. This specification does not support transfer of two keys. The method indicates the mechanism to be used to obtain a usable key by external means, or from the encoded encryption key given. The URI refers to the data containing the key, and may require additional authentication before the key can be returned.

When a request is made to the given URI, the reply should specify the encoding for the key. The user should be prompted for the key when attempting to join the session, and this user-supplied key should then be used to Handley, et al.

It is important to ensure that the secure channel is with the party that is authorised to join the session, not an intermediary: if a caching proxy server is used, it is important to ensure that the proxy is either trusted or unable to access the SDP.

Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both. These are referred to as "media-level" attributes and add information about the media stream. Attribute fields can also be added before the first media field; these "session-level" attributes convey additional information that applies to the conference as a whole rather than to individual media. These are binary attributes, and the presence of the attribute conveys that the attribute is a property of the session.

Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular. Unlike other text fields, attribute values are NOT normally affected by the "charset" attribute as this would make comparisons against known values problematic.

However, when an attribute is defined, it can be defined to be charset dependent, in which case its value should be interpreted in the session charset rather than in ISO If an attribute is received that is not understood, it MUST be ignored by the receiver. A session description may contain a number of media descriptions. Currently defined media are "audio", "video", "text", "application", and "message", although this list may be extended in the future see Section 8. For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple transport ports.

In such a case, the ports used depend on the transport protocol. This implies that, unlike limited past practice, there is no implicit grouping defined by such means and an explicit grouping framework for example, [ 18 ] should instead be used to express the intended semantics.

In addition, relays and monitoring tools that are transport-protocol-specific but format-independent are possible. The fourth and any subsequent sub-fields describe the format of the media. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session.

SDP Attributes The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. Registration procedures for new attributes are defined in Section 8. This is to enable a receiver to filter unwanted sessions by category. There is no central registry of categories. It is a session-level attribute, and it is not dependent on charset. This allows a receiver to select interesting session based on keywords describing the purpose of the session; there is no central registry of keywords.

It is a session-level attribute. This is probably only meaningful for audio data, but may be used with other media types if it makes sense. It is a media-level attribute, and it is not dependent on charset.

This attribute is probably only meaningful for audio data, but may be used with other media types if it makes sense. Note that this attribute was introduced after RFC , and non-updated implementations will ignore this attribute.

It also provides information on the clock rate and encoding parameters. It is a media-level attribute that is not dependent on charset.

As an example of a static payload type, consider u-law PCM coded single-channel audio sampled at 8 kHz. For video streams, no encoding parameters are currently specified. Note: RTP audio formats typically do not include information about the number of samples per packet.

It can be either a session- or media- level attribute, and it is not dependent on charset. Note that recvonly applies to the media only, not to any associated control protocol e. This is necessary for interactive conferences with tools that default to receive-only mode.

It can be either a session or media-level attribute, and it is not dependent on charset. If none of the attributes "sendonly", "recvonly", "inactive", and "sendrecv" is present, "sendrecv" SHOULD be assumed as the default for sessions that are not of the conference type "broadcast" or "H" see below.

An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute, but would normally only be used as a media attribute.

It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol e. This is necessary for interactive conferences where users can put other users on hold.

No media is sent over an Handley, et al. It specifies the orientation of a the workspace on the screen. It is a media-level attribute. Permitted values are "portrait", "landscape", and "seascape" upside-down landscape. Suggested values are "broadcast", "meeting", "moderated", "test", and "H". Specifying the attribute "type:H" indicates that this loosely coupled session is part of an H.

Media tools should be started "recvonly". Specifying the attribute "type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users.

The type attribute is a session-level attribute, and it is not dependent on charset. IANA Considerations MSRP Port URI Schema MSRP Scheme SDP Transport Protocol SDP Attribute Names Accept Types Wrapped Types Max Size Contributors and Acknowledgments Normative References Informative References Introduction A series of related instant messages between two or more parties can be viewed as part of a "message session", that is, a conversational exchange of messages with a definite beginning and end.

This is in contrast to individual messages each sent independently. Messaging schemes that track only individual messages can be described as "page-mode" messaging, whereas messaging that is part of a "session" with a definite start and end is called "session-mode" messaging. Session-mode messaging has a number of benefits over page-mode messaging, however, such as explicit rendezvous, tighter integration with other media-types, direct client-to-client operation, and brokered privacy and security.

The exchange is carried by some signaling protocol, such as SIP [ 4 ]. This allows a communication user agent to offer a messaging session as one of the possible media-types in a session. For instance, Alice may want to communicate with Bob. Alice doesn't know at the moment whether Bob has his phone or his IM client handy, but she's willing to use either. She sends an invitation to a session to the address of record she has for Bob, sip:bob example.

Her invitation offers both voice and an IM session. The SIP services at example. Bob accepts the invitation at his IM client, and they begin a threaded chat conversation. This session model allows message sessions to be integrated into advanced communications applications with little to no additional protocol development. For example, during the above chat session, Bob decides Alice really needs to be talking to Carol.

Bob can transfer [ 21 ] Alice to Carol, introducing them into their own messaging session. Messaging sessions can then be easily integrated into call-center and dispatch environments using third-party call control [ 20 ] and conferencing [ 19 ] applications. MSRP relay devices [ 23 ] referred to herein as "relays" are specified in a separate document.

An endpoint that implements this specification, but not the relay specification, will be unable to introduce relays into the message path, but will still be able to interoperate with peers that do use relays. This document consistently refers to a "message" as a complete unit of MIME or text content. In some cases, a message is split and delivered in more than one MSRP request.

Each of these portions of the complete message is called a "chunk". SIP meets these requirements for a rendezvous mechanism. The receiving SIP user agent can accept the invitation and include an answer session- description that acknowledges the choice of media. Note: Some lines in the examples are removed for clarity and brevity. SEND requests are used to deliver a complete message or a chunk a portion of a complete message , while REPORT requests report on the status of a previously sent message, or a range of bytes inside a message.

When Alice receives Bob's answer, she checks to see if she has an existing connection to Bob. Alice then delivers a SEND request to Bob with her initial message, and Bob replies indicating that Alice's request was received successfully.

In this typical case, there is just one "hop", so there is only one URI in each path header field. She also includes a message ID, which she can use to correlate status reports with the original message.

Next she puts the actual content. If Alice wants to deliver a very large message, she can split the message into chunks and deliver each chunk in a separate SEND request. The message ID corresponds to the whole message, so the receiver can also use it to reassemble the message and tell which chunks belong with which message.

Chunking is described in more detail in Section 5. The Byte-Range header field identifies the portion of the message carried in this chunk and the total size of the message. Alice can also specify what type of reporting she would like in response to her request.

This is especially useful if Alice sent a series of SEND requests containing chunks of a single message. More on requesting types of reports and errors is described in Section 5. Alice and Bob can reject requests to URIs they are not expecting to service and can correlate the specific URI with the probable sender. Alice and Bob can also use Campbell, et al. For this reason, a URI with the "msrps" scheme makes no assertion about the security properties of other hops, just the next hop.

An adjacent pair of busy MSRP nodes for example, two relays can easily have several sessions, and exchange traffic for several simultaneous users. The nodes can use existing connections to carry new traffic with the same destination host, port, transport protocol, and scheme.

MSRP nodes can keep track of how many sessions are using a particular connection and close these connections when no sessions have used them for some period of time. Connection management is discussed in more detail in Section 5.

Key Concepts 5. Long chunks may be interrupted in mid- transmission to ensure fairness across shared transport connections. To support this, MSRP uses a boundary-based framing mechanism. The start line of an MSRP request contains a unique identifier that is also used to indicate the end of the request. Included at the end of the end-line, there is a flag that indicates whether this is the last chunk of data for this message or whether the message will be continued in a subsequent chunk.

There is also a Byte-Range header field in the request that indicates the overall position of this chunk inside the complete message. The ability to interrupt messages allows multiple sessions to share a TCP connection, and for large messages to be sent efficiently while not blocking other messages that share the same connection, or even the same MSRP session.

Any chunk that is larger than octets MUST be interruptible. For example, the TCP peer may be a relay device that connects to many other peers.

Such a device will scale better if each peer does not create a large number of connections. Note that in the above example, the initial chunk was interruptible for the sake of example, even though its size is well below the limit for which interruptibility would be required. The chunking mechanism only applies to the SEND method, as it is the only method used to transfer message content.

This was done to allow the protocol to work with relays, which are defined in a separate document, to provide a complete path to the end recipient. The receiver MUST quickly accept or reject the request.

If the receiver initially accepted the request, it still may then do things that take significant time to succeed or fail. The XMPP side may later indicate that the request did not work. At this point, the MSRP receiver may need to indicate that the request did not succeed. There are two important concepts here: first, the hop-by-hop delivery of the request may succeed or fail; second, the end result of the request may or may not be successfully processed.

The first type of status is referred to as "transaction status" and may be returned in response to a request. The original sender of a request can indicate if they wish to receive reports for requests that fail, and can independently indicate if they wish to receive reports for requests that succeed. A receiver only sends a success REPORT if it knows that the request was successfully delivered, and the sender requested a success report.

A receiver only sends a failure REPORT if the request failed to be delivered and the sender requested failure reports. This document describes the behavior of MSRP endpoints. Two header fields control the sender's desire to receive reports. The Success-Report header field can have a value of "yes" or "no" and the Failure-Report header field can have a value of "yes", "no", or "partial".

The combinations of reporting are needed to meet the various scenarios of currently deployed IM systems.

Success-Report might be "no" in many public systems to reduce load, but might be "yes" in certain enterprise systems, such as systems used for securities trading. A Failure-Report value of "no" is useful for sending system messages such as "the system is going down in 5 minutes" without causing a response explosion to the sender.

A Failure-Report of "yes" is used by many systems that wish to notify the user if the message failed. A Failure-Report of "partial" is a way to report errors other than timeouts. Timeout error reporting requires the sending hop to run a timer and the receiving hop to send an Campbell, et al. Some systems don't want the overhead of doing this. The term "partial" denotes that the hop-by-hop acknowledgment mechanism that would be required with a Failure-Report value of "yes" is not invoked.

Thus, each device uses only "part" of the set of error detection tools available to them. This allows a compromise between no reporting of failures at all, and reporting every possible failure. For example, with "partial", a sending device does not have to keep transaction state around waiting for a positive acknowledgment.

But it still allows devices to report other types of errors. The receiving device could still report a policy violation such as an unacceptable content-type, or an ICMP error trying to connect to a downstream device.

When a new MSRP session is created, the initiating endpoint MUST act as the "active" endpoint, meaning that it is responsible for opening the transport connection to the answerer, if a new connection is required. However, this requirement MAY be weakened if standardized mechanisms for negotiating the connection direction become available and are implemented by both parties to the connection.

If the connection is not authenticated with TLS, and the active endpoint did not send an immediate request, the passive endpoint would have no way to determine who had connected, and would not be able to safely send any requests towards the active party until after the active party sends its first request. The Campbell, et al. At this point, the device that initiated the connection can assume that this connection is with the correct host.

In this case, a mechanism to ensure that the peer used a correct certificate MUST be used. See Section If the connection used mutual TLS authentication, and the TLS client presented a valid certificate, then the element accepting the connection can verify the identity of the connecting device by comparing the hostname part of the target URI in the SDP provided by the peer device against the SubjectAltName in the client certificate. When mutual TLS authentication is not used, the listening device MUST wait until it receives a request on the connection, at which time it infers the identity of the connecting device from the associated session description.

The element that accepted the connection looks up the URI in the received request, and determines which session it matches. If no match exists, the node MUST reject the request with a response. The node MUST also check to make sure the session is not already in use on another connection.

If the session is already in use, it MUST reject the request with a response. If it were legal to have multiple connections associated with the same session, a security problem would exist.

If the initial SEND request is not protected, an eavesdropper might learn the URI, and use it to insert messages into the session via a different connection.

When either endpoint notices such a failure, it MAY attempt to re-create any such sessions. If a replacement session is successfully created, endpoints MAY attempt to resend any content for which delivery on the original session could not be confirmed.

If it does this, the Message-ID values for the Campbell, et al. The specific action that an endpoint takes when it receives a duplicate message is a matter of local policy, except that it SHOULD NOT present the duplicate messages to the user without warning of the duplication.

Note that acknowledgments as needed based on the Failure-Report and Success-Report settings are still necessary even for requests containing duplicate content. When endpoints create a new session in this fashion, the chunks for a given logical message MAY be split across the sessions.

This document describes the former usage; the latter usage is described in the MSRP relay specification [ 23 ]. The syntax is described in Section 9. MSRP URIs are primarily expected to be generated and exchanged between systems, and are not intended for "human consumption". The constructions for "authority", "userinfo", and "unreserved" are detailed in RFC [ 10 ].

Documents that provide bindings on other transports should define respective parameters for those transports. The session-id part identifies a particular session of the participant. The absence of the session-id part indicates a reference to an MSRP host device, but does not refer to a particular session at that device.

A particular value of session-id is only meaningful in the context of the associated authority; thus, the authority component can be thought of as identifying the "authority" governing a namespace for the session-id. This value is not a default, as the URI negotiation process described herein will always include explicit port numbers. This makes life easier for network administrators who need to manage firewall policy for MSRP.

The authority component will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the session itself. The scheme MUST match.

Scheme comparison is case insensitive. Percent-encoding normalization [ 10 ] applies; that is, if any percent-encoded nonreserved characters exist in the authority component, they must be decoded prior to comparison. Userinfo Campbell, et al. Otherwise, the authority component is compared as a case-insensitive character string. A URI with an explicit port is never equivalent to another with no port specified. The session-id part is compared as case sensitive.

A URI without a session-id part is never equivalent to one that includes one. URIs with different "transport" parameters never match. Two URIs that are identical except for transport are not equivalent. The transport parameter is case insensitive. This process assumes that the connection port is always known prior to resolution. The introduction of relays creates situations where this is not the case. For example, when a user configures her client to use a relay, it is desirable that the relay's MSRP URI is easy to remember and communicate to humans.

Often this type of MSRP will omit the port number. Therefore, the relay specification [ 23 ] describes additional steps to resolve the port number.

For example, MSRP endpoints may use other mechanisms to discover relays, which are beyond the scope of this document. Method-Specific Behavior 7. Constructing Requests To form a new request, the sender creates a transaction identifier and uses this and the method name to create an MSRP request start line.

Therefore, it MUST contain at least 64 bits of randomness. The processing then becomes method specific. Additional method-specific header fields are added as described in the following sections. After any method-specific header fields are added, processing continues to handle a body, if present. It may contain other MIME-specific header fields. Non-SEND requests are not intended to carry message content, and are therefore not interruptible.

Although this document does not discuss any particular usage of bodies in non-SEND requests, they may be useful in the future for carrying security or identity information, information about a message in progress, etc. The 10K size limit was chosen to be large enough for most of such applications, but small enough to avoid the fairness issues caused by sending arbitrarily large content in non-interruptible method bodies.

A request without a body MUST contain an end-line after the final header field. No extra CRLF will be present between the header section and the end-line. Requests with no bodies are useful when a client wishes to send "traffic", but does not wish to send content to be rendered to the peer user. For example, the active endpoint sends a SEND request immediately upon establishing a connection. If it has nothing to say at the moment, it can send a request with no body.

Bodiless requests may also be used in certain applications to keep Network Address Translation NAT bindings alive, etc. A request with an empty body will have a Content-Type header field value and will generally be rendered to the recipient according to the rules for that type. The end-line that terminates the request MUST be composed of seven "-" minus sign characters, the transaction ID as used in the start line, and a flag character. If the sender is aborting an incomplete message, and intends to send no further chunks in that message, the flag MUST be a " ".

If the request contains a body, the sender MUST ensure that the end- line seven hyphens, the transaction identifier, and a continuation flag is not present in the body. Some implementations may choose to scan for the closing sequence as they send the body, and if it is encountered, simply interrupt the chunk at that point and start a new transaction with a different transaction identifier to carry the rest of the body.

Other implementations may choose to scan the data and ensure that the body does not contain the transaction identifier before they start sending the transaction.

Once a request is ready for delivery, the sender follows the connection management Section 5. The value MUST be highly unlikely to be repeated by another endpoint instance, or by the same instance in the future.