A discussion of how federation is accomplished isn’t complete without an in-depth look at the flow of messages and the protocols that accomplish it.
SIP is a signaling protocol—it uses verbs, or methods, much like Simple Mail Transfer Protocol (SMTP) does to talk to server processes. Many of these methods are clear as to what they are doing when presented to the server process.
The scenario we will examine is one in which two federated domains each have a user who wants to use IM with the user on the other domain. The domains we will use are Litwareinc.com and Fabrikam.com. Our users, Kim Akers ([email protected]) and John Peoples ([email protected]) communicate frequently by Office Communicator. They need to enter each other’s SIP contact address in Communicator. Because there is no address book service between two federated enterprises, you need to know the contact information for the other person, similar to using SMTP.
John Peoples has entered [email protected] into his Communicator client, and Kim Akers has entered [email protected] into hers. John and Kim are now ready to initiate their communication, as shown in Figure 7-23.
If you use logging from the pool server (decoded by the snooper.exe tool in the Office Communications Server 2007 R2 Resource Kit tools [see Chapter 20, for more information about using the Snooper tool]) and the Access Edge Server, what you see is a great deal more than the required message elements. Numerous DIAGNOSTIC messages and other messages ensure that the flow is correct and that the messages are arriving properly. The continued communication between the pool server and the Edge Server has nothing to do with maintaining communication for Kim and John.
Note
The following discussion tracks the most important steps and is not a full step-by-step look at each and every message. The missing steps are typically OK or DIAGNOSTIC messages that don’t provide anything more than a simple "I heard you." To avoid redundancy, the analysis of each type of message is limited unless something was new to learn or observe in a subsequent message. The outlined steps depend on the diagram presented in Figure 7-23.
Important
The steps in the following traces depend on the diagram presented in Figure 7-23. Steps are missing because we are not following each step, only those that are not redundant.
The first part of the message flow begins with the initial discussion of the Communicator client with the home pool server. The client who is logging in must register with the pool to which she is a member. This tells the server where the client can be reached. Finally, note that the certificates that were prepared are being used to establish TLS.
TL_INFO(TF_PROTOCOL) [0]06F4.0CDC::08/22/2007-19:09:27.536.
00000440 (SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))
$$begin_record
Instance-Id: 00000280
Direction: incoming
Peer: 10.0.0.24:2065
Message-Type: request
Start-Line: REGISTER sip:vdomain1.com SIP/2.0
From: <sip:[email protected]>;tag=b801f3431d;epid=5d3080be61
To: <sip: [email protected]>
CSeq: 2 REGISTER
Call-ID: 091eeac004fb4d94bee8845581203051
Via: SIP/2.0/TLS 10.0.0.24:2065
Max-Forwards: 70
Contact: <sip:10.0.0.24:2065;transport=tls;ms-opaque=57561cdbc3>;methods="INVITE,
MESSAGE, INFO, OPTIONS, BYE,
CANCEL, NOTIFY, ACK, REFER, BENOTIFY";proxy=replace;
+sip.instance=
"<urn:uuid:20C60920-2E75-5AB3-9252-DF040FAD120E>"
User-Agent: UCCP/2.0.6502.502 OC/2.0.6502.502 (Microsoft Office Communicator)
Authorization: Kerberos qop="auth", realm=
"SIP Communications Service", targetname=
"sip/pool.litwareinc.com", gssapi-data=
"YIIEmQYJKoZIhvcSAQICAQBuggSIMII
<snip of gssapi data>
1y5947WB1ux7FUNWDi6hzm44H9DHWrnglDmYG4jDxmW+razdEP1l1MUXvuAbE=",
version=3
Supported: gruu-10, adhoclist, msrtc-event-categories
Supported: ms-forking
ms-keep-alive: UAC;hop-hop=yes
Event: registration
Content-Length: 0
Message-Body:Step 3: SUBSCRIBE sip:[email protected] SIP/2.0
The registered user agent uses a SUBSCRIBE method to receive notifications on the change of state or other elements. Specifically, the user agent needs to know about events that occur that are of interest, and it establishes event handlers that the client is interested in so that the proper notification is sent when that event is triggered. There is no corresponding UNSUBSCRIBE method to terminate a SUBSCRIBE method. However, a SUBSCRIBE message is sent with the Expires header field set to 0. Following the conversation in the message flow is simplified by following the tag and epid fields. Also, note the user agent. The SUBSCRIBE request occurs mostly in the last couple of lines.
TL_INFO(TF_PROTOCOL) [0]06F4.0CDC::08/22/2007-19:09:27.586.
00000473 (SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))
$$begin_record
Instance-Id: 00000284
Direction: incoming
Peer: 10.0.0.24:2065
Message-Type: request
Start-Line: SUBSCRIBE sip:[email protected] SIP/2.0
From: <sip:[email protected]>;tag=76293b8509;epid=5d3080be61
To: <sip:[email protected]>
CSeq: 1 SUBSCRIBE
Call-ID: b6076edf0ea146e594624fe3ae1ba0f7
Via: SIP/2.0/TLS 10.0.0.24:2065
Max-Forwards: 70
Contact: <sip:[email protected];opaque=user:epid:
IAnGIHUus1qSUt8ED60SDgAA;gruu>
User-Agent: UCCP/2.0.6502.502 OC/2.0.6502.502 (Microsoft Office
Communicator)
Event: vnd-microsoft-roaming-self
Accept: application/vnd-microsoft-roaming-self+xml
Supported: com.microsoft.autoextend
Supported: ms-benotify
Proxy-Require: ms-benotify
Supported: ms-piggyback-first-notify
Proxy-Authorization: Kerberos qop="auth", realm=
"SIP Communications Service", opaque="3A852553",
crand="c458b6ff", cnum="2", targetname="sip/pool.litwareinc.com",
response="602306092a864886f71201020201011100ffffffffc098b3
7c7b9497ccca0f8eb3b407cd5c"
Content-Type: application/vnd-microsoft-roaming-self+xml
Content-Length: 174
Message-Body: <roamingList xmlns="http://schemas.microsoft.com/2006/09/sip/roaming-self">
<roaming type="categories"/><roaming type="containers"/>
<roaming type="subscribers"/></roamingList>
$$end_recordThe response to this message is a pair of verbose 200 OK messages that informs the client what they are now subscribed for and confirms the events. A snippet of one of those messages is shown next. Note that there is no defined expire time because the server expects to see a SUBSCRIBE with the Expires: 0 field to terminate the SUBSCRIBE.
<category name="contactCard" instance="0" publishTime="2007-08-22T18:57:41.610"
container="0" version="2" expireType="static">
<contactCard xmlns="http://schemas.microsoft.com/2006/09/sip/
contactcard" >
<identity >
<name >
<displayName >
Kim Akers</displayName>
</name>
<email >
[email protected]</email>
</identity>
</contactCard>
</category>
<category name="note" instance="0" publishTime=
"2007-08-22T19:01:00.317" container="32000" version="1"
expireType="static"/>
<category name="note" instance="0" publishTime=
"2007-08-22T19:01:00.317" container="100" version="1"
expireType="static"/>
<category name="state" instance="0" publishTime=
"2007-08-22T19:01:00.317" container="32000" version="1"
expireType="static">
<state xmlns="http://schemas.microsoft.com/2006/09/sip/state" xmlns:xsi="http://www.
w3.org/2001/XMLSchema-instance" manual=
"false" xsi:type="aggregateState" ><availability >
18500</availability><endpointLocation ></endpointLocation>
</state>
</category>
<category name="state" instance="0" publishTime=
"2007-08-22T19:09:05.720" container="400" version="1"
expireType="static">Step 5: SERVICE sip:[email protected] SIP/2.0
The SERVICE method is used in this case to turn the presence on for Kim Akers. At this point, Kim can now be seen online and anyone who has her in his contact list will be able to see that she is online (assuming, of course, that she hasn’t specifically set her presence as Offline) and what her current status is.
TL_INFO(TF_PROTOCOL)
[0]06F4.0CDC::08/22/2007-19:10:04.517.0000055d
(SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 0000029B
Direction: incoming
Peer: 10.0.0.24:2065
Message-Type: request
Start-Line: SERVICE sip:[email protected] SIP/2.0
From: <sip:[email protected] >;tag=446e225cd5;epid=5d3080be61
To: <sip:[email protected] >
CSeq: 1 SERVICE
Call-ID: a613e9b91a774db4bf65ba293814ad92
Via: SIP/2.0/TLS 10.0.0.24:2065
Max-Forwards: 70
Contact: <sip:[email protected];opaque=user:epid:
IAnGIHUus1qSUt8ED60SDgAA;gruu>
User-Agent: UCCP/2.0.6502.502 OC/2.0.6502.502 (Microsoft Office
Communicator)
Proxy-Authorization: Kerberos qop="auth", realm=
"SIP Communications Service", opaque="3A852553",
crand="87e1e7a1", cnum="11",
targetname="sip/pool.litwareinc.com",
response="602306092a864886f71201020201011100ffffffffdf
2ec24a2d6d546878a3ddc6ade6690d"
Content-Type: application/msrtc-presence-setsubscriber+xml
Content-Length: 162
Message-Body: <publish
xmlns="http://schemas.microsoft.com/2006/09/sip/rich-
presence"><publications uri="sip:[email protected]">
<publication categoryName="device" instance="722818101"
container="2" version="0" expireType="endpoint"><device
xmlns="http://schemas.microsoft.com/2006/09/sip/device"
endpointId="87AAC0AD-3A90-5901-A799-B4672392F3BF">
<capabilities preferred="false" uri="sip:[email protected]">
<text capture="true" render="true" publish="false"/><gifInk
capture="false" render="true" publish="false"/><isfInk
capture="false" render="true" publish="false"/></capabilities>
<timezone>00:00:00+01:00
</timezone><machineName>CLIENT</machineName></device>
</publication><publication categoryName="state"
instance="850482499" container="3" version="0" expireType=
"endpoint"><state xmlns="http://schemas.microsoft.com
/2006/09/sip
/state" manual="false" xmlns:xsi="http://www.w3.org/2001
/XMLSchema-instance" xsi:type="machineState"><availability>3500</availability>
<endpointLocation></endpointLocation></state></publication>
<publication categoryName="state" instance="850482499"
container="2" version="0" expireType="endpoint"><state>
xmlns="http://schemas.microsoft.com/2006/09/sip/state"
manual="false"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:type="machineState"><availability>3500</availability>
<endpointLocation></endpointLocation></state></publication>
</publications></publish>
$$end_recordThis completes the initial "getting online" sequence—Kim Akers is online, and John Peoples is online as well. If John and Kim have each other in their Contacts list, they should be able to see that the other person is online by use of the presence indicator. We’ve initiated and opened the Office Communicator client, signed in to our pool (home) server, and set our current presence status.
Now that Kim and John are ready to start a conversation, let’s examine the details of adding users to the remote user’s pool via the SUBSCRIBE and NOTIFY messages from one enterprise to another across the federated connection, as shown in Figure 7-24.
Note
The following discussion tracks the most important steps and is not a full step-by-step look at each and every message. Also, to avoid redundancy, the analysis of each type of message is limited unless there was something new to learn or observe in a subsequent message.
Important
As in the previous example, this set of traces depends on the steps outlined in Figure 7-24. We are not following every step, just those that would be important to understand the flow of traffic and data. This information is useful for troubleshooting purposes.
Step 1: SUBSCRIBE sip:[email protected] SIP/2.0
John and Kim are now logged in and signed in to their respective enterprises. Now, the respective users have to be able to get enough information to be able to receive event notifications about their contact records. Because Kim and John have each other’s records, the client knows that it has to subscribe to the home pool of the other user. The flow begins with a SUBSCRIBE to Fabrikam.com via Kim’s home pool and Access Edge Servers.
TL_INFO(TF_PROTOCOL)
[0]05F8.0944::08/22/2007-19:10:01.170.000007fe
(SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 000000B6
Direction: outgoing;source="internal edge";destination=
"external edge"
Peer:accessproxy.litwareinc.com:5061
Message-Type: request
Start-Line: SUBSCRIBE sip:[email protected] SIP/2.0
From: "Kim Akers"<sip:[email protected]>;tag=b5942d9dd9;
epid=7469ade8c2
To: <sip:[email protected]>
CSeq: 1 SUBSCRIBE
Call-ID: f6c1d48ef2084b82b080aedeb3f31707
Record-Route: <sip:accessedge.litwareinc.com:5061;transport=tls;
epid=7469ade8c2;lr>;tag=CC4625642D8B2D9A579AD58F130DD603
Via: SIP/2.0/TLS 11.0.0.25:1061;branch=z9hG4bKEEEBA844.0226596C;branched=FALSE;
ms-internal-info="abnlJuPbnBNx-r4dTTJSZtvB0OuVACJlls2H2kKQAA"
ms-asserted-verification-level: ms-source-verified-user=verified
Max-Forwards: 68
Via: SIP/2.0/TLS 10.0.0.20:1504;branch=z9hG4bK27C8ADD2.3872BC78;branched=FALSE;
ms-received-port=1504;ms-received-cid=1600
Via: SIP/2.0/TLS 10.0.0.24:1251;ms-received-port=1251;
ms-received-cid=1F00
<SNIP>On the Fabrikam.com Access Edge Server, we can find the SUBSCRIBE message as it comes into the server:
TL_INFO(TF_PROTOCOL)
[0]09B4.0CAC::08/22/2007-19:10:01.537.00000009
(SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 0000022B
Direction: incoming;source="external edge";destination=
"internal edge"
Peer: accessedge.litwareinc.com:1061
Message-Type: request
Start-Line: SUBSCRIBE sip:[email protected] SIP/2.0
From: "Kim Akers"<sip:[email protected]>;tag=b5942d9dd9;
epid=7469ade8c2
To: <sip:[email protected]>
CSeq: 1 SUBSCRIBE
Call-ID: f6c1d48ef2084b82b080aedeb3f31707
Record-Route: sip:edgeserver.fabrikam.com:5061;transport=tls;
epid=7469ade8c2;lr;tag=CC4625642D8B2D9A579AD58F130DD603
<snip>The DIAGNOSTIC message that is seen right after the preceding message shows that our federation is recognized and the SIP domain has been recognized:
TL_INFO(TF_DIAG) [0]09B4.0CAC::08/22/2007-19:10:01.577.0000000d
(SIPStack,SIPAdminLog::TraceDiagRecord:
SIPAdminLog.cpp(144))$$begin_record
LogType: diagnostic
Severity: information
Text: The message has an Allowed Partner Server domain
SIP-Start-Line: SUBSCRIBE sip:[email protected] SIP/2.0
SIP-Call-ID: f6c1d48ef2084b82b080aedeb3f31707
SIP-CSeq: 1 SUBSCRIBE
Peer: accessedge.litwareinc.com:1061
Data: domain="litwareinc.com"
$$end_recordIn this set of actions, several things happen in a quick sequence. If you look at the message flow, you’ll see that the home server sends a BENOTIFY message to John Peoples’s client, and it also sends a 200 OK message back to Kim Akers. The 200 OK tells her client that it is now subscribed successfully on the Fabrikam.com domain and, much like the preceding SUBSCRIBE message, it also indicates what the SUBSCRIBE contained.
The BENOTIFY is a bit different. When a SUBSCRIBE comes in, we’re subscribing to the pool on which a user is a member. The home server has to tell the client that the SUBSCRIBE is taking place, and the client now has some things to do. The BENOTIFY to John’s client looks like this:
TL_INFO(TF_PROTOCOL) [0]06F4.0AF8::08/22/2007-19:10:04.507.0000055a
(SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 0000029A
Direction: outgoing;source="local"
Peer: 11.0.0.25:2065
Message-Type: request
Start-Line: BENOTIFY sip:11.0.0.25:2065;transport=tls;
ms-opaque=57561cdbc3;ms-received-cid=2D00 SIP/2.0
From: <sip:[email protected]>;tag=55D24D67
To: <sip: [email protected] >;tag=50d3171d57;epid=5d3080be61
CSeq: 2 BENOTIFY
Call-ID: 63dab314323b44a08637aa1775518841
Via: SIP/2.0/TLS 11.0.0.35:5061;branch=z9hG4bKA56C7273.03AB7EC2;branched=FALSE
Authentication-Info: Kerberos rspauth="602306092A864886F712010
20201011100FFFFFFFFC64C8A2A6175A0639CA680B771C00C1F",
srand="911862A4", snum="14", opaque="3A852553", qop="auth",
targetname="sip/pool.fabrikam.com", realm="SIP Communications
Service"
Max-Forwards: 70
Content-Length: 163
Content-Type: application/vnd-microsoft-roaming-contacts+xml
Event: vnd-microsoft-roaming-contacts
subscription-state: active;expires=52019
Message-Body: ----****MESSAGE BODY DELETED****----
$$end_recordSteps 3 and 4 are going to respond to the BENOTIFY and initiate a SERVICE method. But just before that, John’s home server ensures that his presence is in an offline state. The SERVICE method fires, and John’s client notifies the home pool server that he has received the BENOTIFY and that he’s ready to communicate. The home pool responds by sending John’s presence to Litwareinc.com, which will be reflected in Kim’s client, and to the state that John indicated when he first signed on.
In Step 5: SERVICE sip:[email protected] SIP/2.0, John initiates a SUBSCRIBE that is destined for the Litwareinc.com domain and that will accomplish the same set of processes that occurred in Fabrikam when Kim initiated her SUBSCRIBE. Also, the BENOTIFY is sent to Kim and the SERVICE method fires, just as it did for John.
John and Kim are both online, can see each other’s presence, and are on the verge of starting the conversation.
Step 8: INVITE sip:[email protected] SIP/2.0
Step 8: INVITE sip:[email protected] SIP/2.0 is the initial INVITE message from Kim Akers to John Peoples—the method used to initiate the actual IM conversation. Note that this is the first message that indicates there is full awareness on the part of both parties, and endpoints:
TL_INFO(TF_PROTOCOL) [0]05F8.0944::08/22/2007-19:10:12.876.00000835
(SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 000000BA
Direction: incoming;source="internal edge";destination=
"external edge"
Peer: pool.litwareinc.com:1504
Message-Type: request
Start-Line: INVITE sip:[email protected] SIP/2.0
From: "Kim Akers"<sip:[email protected]>;tag=af89c73ee3;
epid=7469ade8c2
To: <sip: [email protected] >
CSeq: 1 INVITE
<snip>
EndPoints: <sip:[email protected]>, <sip:[email protected]>
Supported: com.microsoft.rtc-multiparty
<snip>Following the INVITE (in steps 9 and 10) is an OK that John’s client received the INVITE and an ACK back to John that Kim has received the OK to the messaging session. At this point, things are pretty much established.
Remember that SIP is a signaling protocol. There is no way to know for sure that the other party received the message unless we respond. Almost everything has an OK associated with it. However, the ACK is unique to the INVITE request because this is a three-way handshake process. Also, you should remember that SIP is generally a one-sided conversation. It is two clients that have established their own message flow. That one responds is merely courtesy and part of the protocol.
In Office Communications Server 2007 R2 instant messaging, it’s the INFO message (step 12) that tells John’s client that Kim is typing and also displays the text "Kim is typing a message" in his client.
<snip> Route: <sip:pool.fabrikam.com:5061;transport=tls;ms-role-rs-to;lr> User-Agent: UCCP/2.0.6502.502 OC/2.0.6502.502 (Microsoft Office Communicator) Supported: timer Content-Type: application/xml Content-Length: 87 Message-Body: <?xml version="1.0"?> <KeyboardActivity> <status status="type" /> </KeyboardActivity> $$end_record
Kim has completed typing and is sending her initial message to John. The message text is not seen in the Snooper tool, which shows the following: Message-Body: ----****MESSAGE BODY DELETED****----.
TL_INFO(TF_PROTOCOL) [0]05F8.0944::08/22/2007-19:10:13.217.000008ba
(SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 000000C4
Direction: outgoing;source="internal edge";destination=
"external edge"
Peer: accessedge.litwareinc.com:5061
Message-Type: request
Start-Line: MESSAGE sip:[email protected];opaque=user:epid:
IAnGIHUus1qSUt8ED60SDgAA;gruu SIP/2.0
From: <sip:[email protected]>;tag=af89c73ee3;epid=7469ade8c2
To: "" <sip:[email protected]>;epid=5d3080be61;
tag=4c8535fa6e
CSeq: 2 MESSAGE
Call-ID: 5c2aad6c090241c9bb3b86753b53cee1
Via: SIP/2.0/TLS 11.0.0.25:1061;branch=z9hG4bK75B30E9F.92A6F7E6;branched=FALSE;
ms-internal-info="abEScJu0wN6e6exY40NhVTSh_aIGKSpvfm2H2kKQAA"
ms-asserted-verification-level: ms-source-verified-user=verified
ms-archiving: TRUE
Max-Forwards: 68
Via: SIP/2.0/TLS 10.0.0.20:1504;branch=z9hG4bK58136098.0DBECCED;branched=FALSE;
ms-received-port=1504;ms-received-cid=1600
<snip>The remainder of the message flow involves a series of back-and-forth MESSAGE, 200 OK, and INFO messages. At the end of the session, they end their conversation—or one person decides to end the session. With the final message that we’re going to look at, one person sends the BYE method and the session is terminated. (Obviously, the other person can reestablish the communication, which involves most of the steps that we’ve reviewed in this section.)
Oddly, not much is interesting about this message. We just simply say BYE.
TL_INFO(TF_PROTOCOL)
[0]05F8.0944::08/22/2007-19:10:31.754.00000923
(SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 000000CA
Direction: outgoing;source="internal edge";destination=
"external edge"
Peer: edgeserver.fabrikam.com:5061
Message-Type: request
Start-Line: BYE sip:[email protected];opaque=user:epid:
IAnGIHUus1qSUt8ED60SDgAA;
gruu SIP/2.0
From: <sip:[email protected]>;tag=af89c73ee3;epid=7469ade8c2
To: "" <sip:[email protected]>;epid=5d3080be61;
tag=4c8535fa6e
CSeq: 3 BYE
Call-ID: 5c2aad6c090241c9bb3b86753b53cee1
Via: SIP/2.0/TLS 11.0.0.25:1061;branch=z9hG4bKD2EEC434.230ACDF5;branched=FALSE;
ms-internal-info="abBF-BCHJPotZZ4WauGOrWULVm-qEjCs312H2kKQAA"
ms-asserted-verification-level: ms-source-verified-user=verified
Max-Forwards: 68
Via: SIP/2.0/TLS 10.0.0.20:1504;branch=z9hG4bKB5A56090.D7906399;branched=FALSE;
ms-received-port=1504;ms-received-cid=1600
Via: SIP/2.0/TLS 10.0.0.24:1251;ms-received-port=1251;
ms-received-cid=1F00
Route: <sip:assessedge.litwareinc.com:5061;transport=tls;
epid=5d3080be61;lr;ms-key-info=jACAANllrITgfVcd4OTHAQEC
AAADZgAAAKQAAErVfkqSMT4KWRwNZJ9pTueIXj9JstdoDPUx9993-kqbW
A6eDmg7tjwUXo9W_VhTmuPGcxExiybWGAshIi4C9dNRNXYQEkyEv7Vl0Y
J1-gEH2ezJXyEclUq3o4RXL5WXqzulCMYmXTt_OwA8gQIeCILVPQY5ty
ZvZMlqg8pQJ4lkFjqA1Nq1R4LKfdXA4s0lf0M7K2cX-iqosQf6sK-or2G
Ice7zj2qhcibEOReEXe6YoIWk-nvDeSTmrDMMzR6TKkEltjA6I5BYkU_Cx
oJ8H9xdLEEjtTWH3Fqn7javve10VaRNywoCNVc_BQ0Z8frx5hKv07frixn
jOuO8FzjthnQA;ms-route-sig=cavUCK1BG4udtUgjn2qUfRLCzTjFdx7R
j28P9FsQAA>
Route: <sip:pool.fabrikam.com:5061;transport=tls;ms-role-rs-to;lr>
User-Agent: UCCP/2.0.6502.502 OC/2.0.6502.502 (Microsoft Office
Communicator)
Content-Length: 0
Message-Body:The subsequent and final 200 OK from [email protected] is step 20:
TL_INFO(TF_PROTOCOL)
[0]05F8.0944::08/22/2007-19:10:31.764.00000926
(SIPStack,SIPAdminLog::TraceProtocolRecord:
SIPAdminLog.cpp(122))$$begin_record
Instance-Id: 000000CB
Direction: incoming;source="external edge";destination=
"internal edge"
Peer: edgeserver.fabrikam.com:5061
Message-Type: response
Start-Line: SIP/2.0 200 OK
From: "John Peoples"<sip:[email protected]>;tag=af89c73ee3;
epid=7469ade8c2
To: "" <sip:[email protected]>;epid=5d3080be61;tag=4c8535fa6e
CSeq: 3 BYE
<snip>