Instant messaging is already widely in use and fairly well understood. It involves two or more individuals communicating with each other using text messages. However, the point of this section is to explain how instant messaging works and to identify the pieces of the system that enable it. Knowing this should help with troubleshooting messaging problems and make it easier to understand how to build applications and integrate systems that work alongside instant messaging.
This example walks Jeremy Los through using his Communicator 2007 client from his office to communicate and interact with coworkers. Instant messaging, sending hyperlinks and emoticons, sharing files, sharing video and audio, and setting up multiple people in a messaging conference are all shown. The scenario shows Jeremy Los interacting with two coworkers, Vadim N. Korepin and Rui Raposo.
Jeremy double-clicks on Vadim N. Korepin, who is in his contact list, to open a messaging window, as shown in Figure 4-13.
Jeremy types the message, "Sorry to hear about the coffee cup :)," into the text box at the bottom of the messaging window, and the message is sent when he hits Enter on the keyboard. This sends a message to Vadim, and Jeremy's message is shown in the current message history window to make tracking the conversation easier, as shown in Figure 4-14.
Vadim receives a notification on his desktop, as shown in Figure 4-15, alerting him that Jeremy sent him a message to initiate a new conversation. This notification can be clicked to open the messaging window, or Vadim can open the window directly from the task bar. (It will be blinking to show that an unread message has been received.)
Jeremy receives the message from his coworker, and it shows up in the message history window, as shown in Figure 4-16.
Jeremy sends a hyperlink to an interesting article by pasting the URL into the text box and sending it, as shown in Figure 4-17.
Vadim receives the hyperlink, but it has a leading "_" inserted, which prevents it from showing up properly as a hyperlink, as shown in Figure 4-18. More information about what is happening here with content filtering is provided in the next section, Examining the Technical Details Behind the Instant Messaging Scenario.
Jeremy sends a file by using the file icon button on the top-right of the messaging window and waits for Vadim to accept the file, as shown in Figure 4-19. Vadim receives a similar view where he can accept the transfer and view the file by clicking on the file icon shown in the messaging history after the download completes.
Jeremy decides to share video, because both he and Vadim have a camera. After they talk briefly, they stop sharing the video session, as shown in Figure 4-20.
This section illustrates what is happening with Communicator 2007 and the network of Office Communications Servers at a level of technical detail that should aid in understanding the product and in thinking through how to troubleshoot message scenarios later, if the need arises. We will explore messaging, sending hyperlinks, and message routing in detail. The following diagram provides an overview of the steps involved in the instant messaging scenario that we are analyzing:
Setting up a conversation at a protocol level is much more involved than it would seem from the user interface. A summary of the protocol messages involved are shown in the diagram shown in Figure 4-21, which also serves as a visual overview of the protocol message flow involved in establishing a messaging session and in sending the first message.
Note
Session establishment using Communicator 2007 works in much the same way that making a phone call through an operator does. The caller (Communicator) first rings the operator (the Office Communications Server Home Server) and asks to be connected to a user. The operator generally tells the caller to hold the line (which is similar to the 100 Trying message from the server) while he looks up the line associated with the person called (which is similar to the server querying its database). Next the operator makes the connection, and the phone of the person called rings (180 Ringing message comes back). Finally, the person called picks up the phone (the 200 OK message sent from the remote contact) and the call is established.
When the first message is sent—"Sorry to hear about the coffee cup :)"—a messaging session is established at a protocol level. This is initiated by an INVITE message to establish the session. The INVITE actually carries the first message in the session and is base64 encoded into the ms-body parameter of the Ms-Text-Format header so that it can be presented with the request to start a messaging session.
Note
Emoticons are icons that represent sequences of underlying text. For example, the colon and right-parenthesis characters can be typed together as ":)" to make a smile, and this is interpreted and shown as an icon in Communicator. You can select icons within Communicator, but they all are simply represented by text underneath. Sometimes this can result in unintended emoticons, which is something you should be aware of. A text sequence like "Answer:Probably" will actually have the ":P" converted into a smiling face with its tongue sticking out. One unfortunate aspect is that users only see this after they send the message, not while they are typing it.
INVITEsip:[email protected] SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70From:<sip:[email protected]>;tag=e57383c75b;epid=aa6d968e18To:<sip:[email protected]>Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 1 INVITEContact:<sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Ms-Text-Format: text/plain; charset=UTF-8; msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZ QBsAGwAJQAyADAARABsAGcAJQAyADAAMgA7ACAARQBGAD0AOwAgAEMATwA9ADAAOwAgAEMAUwA9ADA AOwAgAFAARgA9ADAACgANAAoADQA;ms-body=U29ycnkgdG8gaGVhciBhYm91dCB0aGUgY29mZmVlIGN1cCA6KQ== Supported: ms-delayed-accept Supported: ms-renders-isf Supported: ms-renders-gif Supported: ms-renders-mime-alternative Ms-Conversation-ID: AceOhaxSC0KoxENJSUqzhraNmoHCew== Supported: timerSupported: ms-senderRoster-Manager:sip:[email protected]EndPoints:<sip:[email protected]>, <sip:[email protected]> Supported: com.microsoft.rtc-multiparty Supported: ms-mspms-keep-alive: UAC;hop-hop=yesSupported: ms-conf-invite Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="E8EA7EDD", crand="e870674a", cnum="19", targetname="sip/srv.contoso.com", response= "602306092a864886f71201020201011100ffffffff3ee9fabb267878a043ed3695933d69f8" Content-Type: application/sdp Content-Length: 205 v=0o=- 0 0 IN IP4 192.168.3.100s=sessionc=IN IP4 192.168.3.100t=0 0 m=message 5060 sip nulla=accept-types:text/rtf application/x-ms-ink image/gif multipart/alternative application/ms-imdn+xml
The body of the message describes more about what capabilities the initiator has, and this is talked about both in the Session Initiation Protocol (SIP) RFC 3261 standard, as well as in Chapter 18, "Background Information," which provides detailed information about SIP.
The first server that receives the message responds with a 100 response, and then the remote client responds immediately to provide a temporary response. However, it does not send a final receipt of confirmation until the invitation is accepted by a user. This three-way handshake establishes the session and allows a negotiation of session information between both clients, as follows:
SIP/2.0100 TryingAuthentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF4CC448BBF8DD25781477D1A85E1D3DBC", srand="EAE80D89", snum="31", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Via: SIP/2.0/TLS 192.168.3.100:1467;ms-received-port=1467;ms-received-cid=A00From:<sip:[email protected]>;tag=e57383c75b;epid=aa6d968e18To:<sip:[email protected]>Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 1 INVITE Content-Length: 0
The remote client sends a temporary response to confirm that it is waiting for the user to respond to the request, as follows:
SIP/2.0180 RingingAuthentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF69BE23EA5A0169F00998D21963CEABF6", srand="44C23DFA", snum="32", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Via: SIP/2.0/TLS 192.168.3.100:1467;ms-received-port=1467;ms-received-cid="A00From:"Jeremy Los"<sip:[email protected]>;tag=e57383c75b;epid=aa6d968e18To:"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 1 INVITE User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Content-Length: 0
The remote client confirms that the invitation is accepted and provides session capability information in the body of the message, as follows:
SIP/2.0200 OKAuthentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF885A98EB35E99BF2452E8B1F57D22F91", srand="B636FA2D", snum="33", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Via: SIP/2.0/TLS 192.168.3.100:1467;ms-received-port=1467;ms-received-cid="A00From:"Jeremy Los"<sip:[email protected]>;tag=e57383c75b;epid="aa6d968e18To:"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 1 INVITERecord-Route:<sip:srv.contoso.com:5061;transport=tls;ms-role-rs-from; ms-role-rs-to;ms-opaque=aaB_D3-f9AM9QxeVkH0WddzAAA;lr;ms-route-sig=aasNJ0Ib7XhG1fWKA4UvKlDEpMRMM2Fwj8K3gtHgAA>Contact:<sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Require: com.microsoft.rtc-multiparty Supported: com.microsoft.rtc-multiparty Supported: ms-sender Supported: ms-renders-isf Supported: ms-renders-gif Supported: ms-renders-mime-alternative Supported: ms-conf-invite Content-Type: application/sdp Content-Length: 222 v=0o=- 0 0 IN IP4 192.168.3.101s=sessionc=IN IP4 192.168.3.101t=0 0 m=message 5060 sip sip:[email protected]=accept-types:text/rtf application/ x-ms-ink image/gif multipart/alternative application/ms-imdn+xml
This response establishes a few things for the dialog so that communications can begin. First, it establishes that both parties are interested in communicating and that they are able to reach each other. Second, it establishes routes and contact points for each user. This tells Communicator how to route messages. Communicator uses the Record-Route and the Contact headers to directly send messages to the end point with which it has established the dialog. The Record-Route header contains a signed route that can easily be validated by the server and used to directly route the request. The Contact header has a unique identifier (the epid, or end-point identifier) that can be used by the home server to route the request to the specific Communicator instance of interest (if multiple instances are logged in). Third, it provides capabilities information through the body to both parties so that the means of communication are known and the interaction can be extended or upgraded as desired. For more details on the body of INVITE messages, refer to Chapter 18.
The initiating client acknowledges the session capabilities and completes the three-way handshake to establish the session, as follows:
ACK sip:srv.contoso.com:5061;transport=tls;ms-role-rs-from;ms-role-rs-to; ms-opaque=aaB_D3-f9AM9QxeVkH0WddzAAA;lr;ms-route-sig=aasNJ0Ib7XhG1fWKA4UvKlDEpMRMM2Fwj8K3gtHgAASIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70From:<sip:[email protected]>;tag=e57383c75b;epid="aa6d968e18To:"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 1 ACKRoute:<sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="E8EA7EDD", crand="e4f67482", cnum="20", targetname="sip/srv.contoso.com", response= "602306092a864886f71201020201011100ffffffffc78b87bfa700f1757a4e60fed1847916" Content-Length: 0
This ACK request finalizes the dialog by using the route set provided to test that it works properly. From this point on, the initiating client expects that the dialog is available and the recipient expects that the dialog is established after the ACK arrives as a confirmation that the route set worked in at least one direction. The first line of the request contains the request URI, which is the information used to route the request. This line contains the information that was sent back in the Record-Route header from the 200 OK response (including the signature). Additionally, the next routing target (gathered from the Contact header in the 200 OK response) is placed in the Route header. Additional information on SIP and routing details is provided in Chapter 18.
Note that this section does not discuss messaging sessions with multiple recipients. This is because after more than two people are involved in a session, a conference is created with which all clients interact. Detailed information on conferencing is covered in Chapter 5, "Conferencing Scenario."
Another message type that you see during interactions is the INFO message. This message is used to send little notifications within an INVITE dialog—to alert the other party when a user is typing a message (before it is sent), for example. Here is an example of the INFO message received by Jeremy from Vadim before his response was sent to signal that he was typing a response. The KeyboardActivity data in the body is the key information being passed by this message, as follows:
INFOsip:192.168.3.100:1467;transport=tls;ms-opaque=7c11559fb8; ms-received- cid=00000A00;grid SIP/2.0 Via: SIP/2.0/TLS 192.168.3.1:5061; branch=z9hG4bKEC902A23.8CE260FA;branched= FALSE;ms-internal-info="ba9qTQQ5XMtq_uYWsHUg3gqjoqThSM4mD6sl50CgAA" Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFFC03B6B0D6388E4EE53C6ABA080FFAC55", srand="53D1DBCD", snum="35", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Max-Forwards: 69 Via: SIP/2.0/TLS 192.168.3.101:1073;ms-received-port=1073;ms-received-cid="C00From:"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392To:"Jeremy Los"<sip:[email protected]>;tag=e57383c75b;epid=aa6d968e18Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 1 INFO Contact: <sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Supported: timer Content-Type: application/xml Content-Length: 87 <?xml version="1.0"?> <KeyboardActivity> <status status="type" /> </KeyboardActivity>
When a message is received (or sent) within a messaging session, a MESSAGE message is used. An example of the MESSAGE received by Jeremy from his coworker (transmitted within the INVITE session by using the same Call-ID) is shown next:
MESSAGEsip:192.168.3.100:1467;transport=tls;ms-opaque=7c11559fb8;ms-received- cid=00000A00;grid SIP/2.0 Via: SIP/2.0/TLS 192.168.3.1:5061;branch=z9hG4bK06E6DAB4.5A2D0AB6; branched=FALSE;ms-internal-info="baj3AsctgNBuSN4A27AfVbksRFndBaLQq2sl50CgAA" Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF3D2E62CC853438235B3E6E21C525BA76", srand="A7C06D90", snum="37", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Max-Forwards: 69 Via: SIP/2.0/TLS 192.168.3.101:1073;ms-received-port=1073;ms-received-cid="C00From:"" <sip:[email protected]>;epid="6fe87e039b;tag=5c939f2392To:"Jeremy Los"<sip:[email protected]>;tag=e57383c75b;epid=aa6d968e18Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 3 MESSAGE Contact: <sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Supported: timer Content-Type: text/rtf Content-Length: 242 { tf1ansiansicpg1252deff0deflang1033{fonttbl{f0fnilfcharset0 MS Shell Dlg 2;}{f1fnil MS Shell Dlg 2;}} {colortbl ; ed0green0lue0;} {*generator Msftedit 5.41.15.1507;}viewkind4uc1pard x720cf1f0fs20thanksf1par }
Note
For privacy purposes, the body of MESSAGE messages is not logged by default, so you usually never see this information in your client or server logs. This option can be enabled only on server logs (not client logs). The registry key to enable this is HKLMSYSTEM CurrentControlSetServicesRtcSrvParameters, where the DWORD value of EnableLoggingAllMessageBodies must be set to 1. This registry key causes the server logs to show message bodies after the server is restarted, but it is important to note that this is a big security and privacy risk and should be used only for educational purposes on test systems.
In MESSAGE messages, the body contains the textual message ("thanks" in this example) to be transmitted, with formatting information wrapping it to describe the font, color, and so on. Additional details on SIP sessions and how they work are explained in Chapter 18.
When a hyperlink or Web link (such as http://www.microsoft.com/rtc) is sent as text to another user, many things are happening in the background. First, the message is sent as raw text along with the rest of the message in a MESSAGE message, just as any other text a user might have typed. However, intermediate internal servers, intermediate Access Edge Servers, and the remote client might interpret, alter, or display the message differently based on policy. Office Communications Server 2007 installs with the Intelligent IM Filter active and allows local intranet URLs. However, it inserts a "_" character in front of Internet URLs to prevent it from showing up as an active hyperlink.
An example that shows the IIMFilter server log processing this request is shown next (in place of the protocol message, which would just contain the content shown in the log). This log can be gathered on the server using the logging tool. Additional details on the logging tool are described in this book's Part VI. The log shown next is summarized where you see ellipses (…) to make it easier to read and to remove information that is not of interest to our example. The log basically tracks the filter, watching message content for clickable URLs and then adding an underscore (_) character to the beginning, as follows:
TL_INFO ... ContentType: text/rtf
TL_INFO ... ReadonlyPrefixLength: 0
TL_INFO ... Content:
'{
tf1ansiansicpg1252deff0deflang1033{fonttbl{f0fnilfcharset0 MS
Shell Dlg 2;}}
{colortbl ;
ed0green0lue0;}
{*generator Msftedit 5.41.15.1507;}viewkind4uc1pard x720cf1f0fs20
http://www.microsoft.com/rtcpar
}'
TL_INFO ... (IIMFilter,IIMFilter.CheckForClickableURL:462.idx(775))( 028F1359 )
http://www.microsoft.com/rtc - URL NOT ignored - SecurityZone = Internet
TL_INFO ... Request modified to convert one or more clickable URLs to unclickable URLs
TL_INFO ... Updated content with ContentType: text/rtf
TL_INFO ... Content:
'{
tf1ansiansicpg1252deff0deflang1033{fonttbl{f0fnilfcharset0 MS
Shell Dlg 2;}}
{colortbl ;
ed0green0lue0;}
{*generator Msftedit 5.41.15.1507;}viewkind4uc1pard x720cf1f0fs20
_http://www.microsoft.com/rtcpar
}'
TL_INFO ... Proxy requestCommunicator also has a group policy setting (EnableURL) that it enforces to either display hyperlinks as clickable text or as raw text to require the user to manually copy the text into a browser. All of this is happening simply to allow more control from the network and to prevent bad links from being circulated or accidentally clicked by unsuspecting users.
Sending a file to another user involves a few SIP transactions and then a direct connection between Communicator clients to transfer the file. The file transfer does not go through any of the server infrastructure at all other than the negotiation transactions. Figure 4-22 provides an overview of the protocol interactions and the establishment of the direct connection between Communicator clients (for the purpose of transferring the file).
When Jeremy initiates a file transfer request, the existing session is used and a MESSAGE is sent where the body identifies that a file is available for transfer, as follows:
MESSAGEsip:srv.contoso.com:5061;transport=tls;ms-role-rs-from;ms-role-rs-to; ms-opaque=aaB_D3-f9AM9QxeVkH0WddzAAA;lr;ms-route-sig= aasNJ0Ib7XhG1fWKA4UvKlDEpMRMM2Fwj8K3gtHgAA SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70From:<sip:[email protected]>;tag=e57383c75b;epid="aa6d968e18To:"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 6 MESSAGE Route: <sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;gruu> Contact: <sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Supported: timer Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="E8EA7EDD", crand="760faa07", cnum="28", targetname="sip/srv.contoso.com", response= "602306092a864886f71201020201011100ffffffff2a46ed40d0acdeacd7bbf79110ea5214" Content-Type: text/x-msmsgsinvite; charset=UTF-8 Content-Length: 234Application-Name:File TransferApplication-GUID: {5D3E02AB-6190-11d3-BBBB- 00C04F795683}Invitation-Command:INVITEInvitation-Cookie:625392Application-File:doc.txtApplication-FileSize: 28Connectivity: NEncryption: R
The body of the message identifies that this is a file transfer request and not a messaging request. The Application-Name parameter specifies that a file transfer is offered, and the Application-File parameter specifies the name of the file. The file size is also specified so that the recipient knows how much it must transfer. The Connectivity parameter identifies whether the client is behind a Network Address Translation (NAT) device or not and an "N" indicates that it is. The Encryption parameter identifies whether the sender supports (S) or requires (R) encryption of the transferred file. This information begins the handshake for the file transfer and provides the Invitation-Cookie for reference in responding to this offer in a later MESSAGE from the recipient.
Note
Office Communications Server 2007 installs with the Intelligent IM Filter active, and it blocks all directly executable binaries and scripts from being transferred. Files with extensions such as *.zip, *.doc, and *.xml are all enabled and allowed by default. To see which extensions are blocked, you can look at the Office Communications Server 2007 MMC snap-in, right-click on the server to select Application Properties, select Intelligent IM Filter, and then move to the File Transfer Filter tab.
For our example, Vadim's Communicator confirms receipt of the MESSAGE offering a file transfer, as follows:
SIP/2.0200 OKAuthentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFF74C5A6869E5717FA67441D92794710E5", srand="F5AE7002", snum="41", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Via: SIP/2.0/TLS 192.168.3.100:1467;ms-received-port=1467;ms-received-cid=A00From:<sip:[email protected]>;tag=e57383c75b;epid="aa6d968e18To:"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 6 MESSAGE Contact: <sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Content-Length: 0
Next, Vadim's Communicator sends a MESSAGE back when Vadim accepts the file transfer to identify where the file should be sent, as follows:
MESSAGEsip:192.168.3.100:1467;transport=tls;ms-opaque=7c11559fb8;ms-received- cid=00000A00;grid SIP/2.0 Via: SIP/2.0/TLS 192.168.3.1:5061;branch=z9hG4bK9310B3FD.583AF9C8; branched=FALSE;ms-internal-info="bamr7aJF7hHA-WG_mThfb47YQEs0tYOvnIsl50CgAA" Authentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFFE00D15EEBF15E83C6D8C14A42A949B80", srand="3B024C50", snum="42", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Max-Forwards: 69 Via: SIP/2.0/TLS 192.168.3.101:1073;ms-received-port=1073;ms-received-cid="C00From:"" <sip:[email protected]>;epid="6fe87e039b;tag=5c939f2392To:"Jeremy Los"<sip:[email protected]>;tag=e57383c75b;epid=aa6d968e18Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 4 MESSAGE Contact: <sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Supported: timer Content-Type: text/x-msmsgsinvite; charset=UTF-8 Content-Length: 302Invitation-Command:ACCEPTInvitation-Cookie:625392Request-Data: IP-Address:Encryption-Key:jdQO/KXdOgzT6pxHI3pG9qc/+HEC0ZchHash-Key:bKJQfXeSgWBpFI2LG0HZ/0QveOJwoBwDIP-Address:192.168.3.101Port:6891PortX: 11178AuthCookie:27079318Request-Data: IP-Address:Sender-Connect: TRUE
This information tells Jeremy's Communicator that it should connect to the IP address and port specified to send the encrypted file with the key specified. The AuthCookie specified is also used on the simple FTP connection between the clients as a handshaking device to disambiguate the session.
Jeremy's Communicator client confirms receipt of the MESSAGE accepting the file transfer, as follows:
SIP/2.0200 OKVia: SIP/2.0/TLS 192.168.3.1:5061;branch=z9hG4bK9310B3FD.583AF9C8;branched=FALSE; ms-internal-info="bamr7aJF7hHA-WG_mThfb47YQEs0tYOvnIsl50CgAA" Via: SIP/2.0/TLS 192.168.3.101:1073;ms-received-port=1073;ms-received-cid="C00From:-id002"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392To:<sip:[email protected]>;tag=e57383c75b;epid=aa6d968e18Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 4 MESSAGE Contact: <sip:[email protected];opaque=user:epid:upbza9anR1KJ-8E7UvWEDQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="E8EA7EDD", crand="bebf384d", cnum="29", targetname="sip/srv.contoso.com", response= "602306092a864886f71201020201011100ffffffff4c249327d5a9c2195e194c3235e84318" Content-Length: 0
At this point, Jeremy's Communicator connects directly to Vadim's Communicator (at the IP address and port specified) and begins a simple FTP session where the encrypted file is transferred. The wire protocol is not explained in detail here, but a quick view of what is happening is laid out simply for completeness in the following code sample. (The use of "Jeremy" and "Vadim" in the example actually refers to the Communicator client each is using.)
[Jeremy connects to Vadim] Vadim sends: VER MSN_SECURE_FTP Jeremy sends: VER MSN_SECURE_FTP Vadim sends: USR [email protected] 27079318 Jeremy sends: FIL 28 Vadim sends: TFR [Jeremy sends binary encrypted data] Vadim sends: BYE 16777989 Jeremy sends: MAC [signature using hash] [Jeremy closes the connection]
The preceding interaction is simply a minimal handshake on a raw socket to transfer the encrypted file with a signature. After this interaction, the file transfer is complete.
Negotiating an audio and video session can involve a lot of handshaking. The protocol messages that were involved are shown in the diagram shown in Figure 4-23, which serves as an overview for the section. However, only the bodies of the INVITE and 200 OK messages are discussed in detail in this section.
When video is added to the session, Jeremy's Communicator client negotiates a new session including video and audio by sending an INVITE message for a new session. For brevity, only the protocol message bodies are shown and irrelevant protocol messages are skipped entirely. The body of the INVITE message from Jeremy's Communicator client follows:
v=0o=- 0 0 IN IP4 192.168.3.100s=sessionc=IN IP4 192.168.3.100b=CT:99980t=0 0m=audio60160 RTP/AVP 114 111 112 115 116 4 8 0 97 101k=base64:WYvabwXemv2PqGEj52+xHzXlpUN+MKRUJ2j2Rra/o/7JGjPiQBJHLM/Gr+xya= candidate:XAP7A3WqUxk5m9zYTfROszesQz9Jdgvoqu5B5zzqwFw 1 7c99RFukBeRXvntIUMo4CA UDP 0.830 192.168.3.100 60160 a= candidate:XAP7A3WqUxk5m9zYTfROszesQz9Jdgvoqu5B5zzqwFw 2 7c99RFukBeRXvntIUMo4CA UDP 0.830 192.168.3.100 21120 a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:OC8ZUW5hfFMjxwMk5GwUARUcuevPVTDjuLAvr93K|2^31|1:1a= crypto:2 AES_CM_128_HMAC_SHA1_80 inline:UrEdZ6/u+pj+MABtYK7y/3/ZL/JSRjHe3tEjNEGn|2^31|1:1a=maxptime:200a=rtcp:2 1120a=rtpmap:114 x-msrta/16000a=fmtp:114 bitrate=12000a=rtpmap:111 SIREN/16000a=fmtp:111 bitrate=16000a=rtpmap:112 G7221/16000a=fmtp:112 bitrate=24000a=rtpmap:115 x-msrta/8000a=fmtp:115 bitrate=12000a=rtpmap:116 AAL2-G726-32/8000a=rtpmap:4 G723/8000a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:97 RED/8000a=rtpmap:101 telephone-event/8000a= fmtp:101 0-16a=encryption:optionalm=video13952 RTP/AVP 121 34 31k= base64:3QA+RtpnuOd4cCaj/rWBfeW+Hn9AvxcLhLDkB9yVzwJVftCkEcBSL+lBAmOua= candidate:PVp0w5+rY86zX6Emqm+9zIGUlfTTOU9iEeBBKRfsvks 1 gt+GQX3LSYECKrIM9skhWg UDP 0.840 192.168.3.100 13952 a= candidate:PVp0w5+rY86zX6Emqm+9zIGUlfTTOU9iEeBBKRfsvks 2 gt+GQX3LSYECKrIM9skhWg UDP 0.840 192.168.3.100 50944 a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:BsqZIvEl3PQRq4kwE8lRxSeSeDRriKAyS6uPIRBY|2^31|1:1a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:E3eOmRQAY7c2fSrzR3zrGX8Z1WUI1lGBRxk7GiH2|2^31|1:1a= maxptime:200a=rtcp:50944a=rtpmap:121 x-rtvc1/90000a=rtpmap:34 H263/90000a= rtpmap:31 H261/90000a=encryption:optional
This INVITE message body asks for an audio/video peer-to-peer conference and offers the media parameters and capabilities for the initiating Communicator client.
The 100 and 180 temporary responses are not shown here for the sake of brevity and because they do not really provide any interesting information. However, the 200 response provides capability information from the recipient, as follows:
v=0o=- 0 0 IN IP4 192.168.3.101s=sessionc=IN IP4 192.168.3.101b=CT:99980t=0 0m=audio10496 RTP/AVP 114 111 112 115 116 4 8 0 97 101a=candidate:jUpPjJEHNyN3RNHn+LlReOz7YZbWN3BpqnNqJw9KSrA 1 9VE2N1fM/Ug4DHk/KSO/xw UDP 0.830 192.168.3.101 10496 a= candidate:jUpPjJEHNyN3RNHn+LlReOz7YZbWN3BpqnNqJw9KSrA 2 9VE2N1fM/Ug4DHk/KSO/xw UDP 0.830 192.168.3.101 53120 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:FxTfuRY3zY0R7EPAvnkKjOlOSm4Dwbc/ov1v1qkB|2^31|1:1a=maxptime:200a= rtcp:53120a=rtpmap:114 x-msrta/16000a=fmtp:114 bitrate=12000a=rtpmap:111 SIREN/16000a=fmtp:111 bitrate=16000a=rtpmap:112 G7221/16000a=fmtp:112 bitrate=24000a=rtpmap:115 x-msrta/8000a=fmtp:115 bitrate=12000a=rtpmap:116 AAL2-G726-32/8000a=rtpmap:4 G723/8000a=rtpmap:8 PCMA/8000a=rtpmap:0 PCMU/8000a=rtpmap:97 RED/8000a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=encryption:optionalm=video14976 RTP/AVP 121 34 31a= candidate:lt+HmBqSsE7M8/xGXLbb4U0SG1drKqrEi/RhuqWA5Eo 1 87LtCGRXUnVdv8WaYO+85Q UDP 0.840 192.168.3.101 14976 a= candidate:lt+HmBqSsE7M8/xGXLbb4U0SG1drKqrEi/RhuqWA5Eo 2 87LtCGRXUnVdv8WaYO+85Q UDP 0.840 192.168.3.101 2304 a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:foe41lE6qfhFItmaGWs13hIJXiAzq98kCZKSJDpB|2^31|1:1a=maxptime:200a=rtcp:2 304a=rtpmap:121 x-rtvc1/90000a=rtpmap:34 H263/90000a=rtpmap:31 H261/90000a=encryption:optional
This response confirms that audio and video are available, as well as identifies the media parameters and capabilities for the client.
An ACK message is sent from Jeremy's Communicator client to finish the handshake, but this is not shown because it does not provide any useful additional information.
A second round INVITE is sent next, with the only change being an additional field (a=remote-candidate) that is added in the body as shown in the following code sample. (The same is true of the 200 OK response.)
... m=audio 60160 RTP/AVP 114 111 112 115 116 4 8 0 97 101a=remote-candidate:jUpPjJEHNyN3RNHn+LlReOz7YZbWN3BpqnNqJw9KSrA... m=video 13952 RTP/AVP 121 34 31a=remote-candidate:lt+HmBqSsE7M8/xGXLbb4U0SG1drKqrEi/RhuqWA5Eo...
Finally, a third round INVITE is sent where the video media is simplified down (the same is true of the 200 OK response) to a single line descriptor, as follows:
... m=video 0 RTP/AVP 34
This whole process is simply a way for the two Communicator clients to exchange information about each other that relates to preferences and capabilities. After this session is finally negotiated and created, User Datagram Protocol (UDP) messages are exchanged between the published IPs and ports for each Communicator client as video and audio are shared. This continues until the conference ends based on a user's request.
When Jeremy closes the messaging window, Communicator sends a BYE message within the dialog that was established in order to alert Vadim's client that the communication dialog is being closed. An example of the BYE message and the response from Vadim's client are shown here for reference:
BYEsip:srv.contoso.com:5061;transport=tls;ms-role-rs-from;ms-role-rs-to; ms-opaque=aaB_D3-f9AM9QxeVkH0WddzAAA;lr; ms-route-sig=aasNJ0Ib7XhG1fWKA4UvKlDEpMRMM2Fwj8K3gtHgAA SIP/2.0 Via: SIP/2.0/TLS 192.168.3.100:1467 Max-Forwards: 70From:<sip:[email protected]>;tag=e57383c75b;epid="aa6d968e18To:"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 8 BYE Route: <sip:[email protected];opaque=user:epid:EfpLp1FJKl6EFEzM2Ml2OQAA;gruu> User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="E8EA7EDD", crand="58dad80d", cnum="51", targetname="sip/srv.contoso.com", response= "602306092a864886f71201020201011100ffffffffec97e0568a70bf53982604eb4d04ebe5" Content-Length: 0
Vadim's Communicator responds to acknowledge that it received the dialog close event, as follows:
SIP/2.0200 OKAuthentication-Info: Kerberos rspauth= "602306092A864886F71201020201011100FFFFFFFFFA46FDE2C8EC5FE1C8E3FBBDC650D58A", srand="A4C56671", snum="76", opaque="E8EA7EDD", qop="auth", targetname="sip/srv.contoso.com", realm="SIP Communications Service" Via: SIP/2.0/TLS 192.168.3.100:1467;ms-received-port=1467;ms-received-cid="A00From:"Jeremy Los"<sip:[email protected]>;tag=e57383c75b;epid="aa6d968e18To:"" <sip:[email protected]>;epid=6fe87e039b;tag=5c939f2392Call-ID:d1a1cdc2192048f7a8e9703774cfebcc CSeq: 8 BYE User-Agent: UCCP/2.0.6093.0 OC/2.0.6093.0 (Microsoft Office Communicator) Content-Length: 0
Additional information about the Session Initiation Protocol is discussed in Chapter 18. However, at this point both clients have cleared any remaining state about the communication dialog and if another message is sent by either of them, a new dialog is established.