A discussion of how federation is accomplished isn't really complete unless there is an in-depth look at the flow of messages and the protocols that accomplish it. So we're going to look at Session Initiation Protocol (SIP) in federation. Because SIP has been discussed at length in other chapters of this book, we won't spend a lot of time on the nuts and bolts of the protocol. But where necessary, we will re-emphasize some attributes that have been covered elsewhere.
First, note that SIP is a signaling protocol—it uses verbs, or methods, much like SMTP does to talk to server processes. And many of the methods are very clear as to what they are doing when presented to the server process.
The scenario we will examine is one where two federated domains each have a user that wants to use IM with the other user. The domains we will use are Contoso.com and Fabrikam.com. Our users, Kim Akers ([email protected]) and John Peoples ([email protected]) communicate frequently by Office Communicator. They really don't know how the communication occurs, as they need to enter only each other's SIP contact address in Communicator. So it can be seen that to connect with a user in a federated enterprise, you need to have the Access Edge Servers configured correctly to speak to the other enterprise's Access Edge Server. Also, there is no address book service between two federated enterprises, so—again, like SMTP—you need to know what the contact information is for the other person.
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, but a lot goes on behind the scenes—and this is what we are going to follow. (See Figure 7-8.)
What you see if you use logging from the pool server (decoded by the snooper.exe tool in the Office Communications Server 2007 Resource Kit tools) and the Access Edge Server is a lot more chatter than the required message elements. A lot of DIAGNOTIC messages and other housekeeping messages ensure that the flow is correct and that the messages are arriving properly. Also, the continued communication between the pool server and the edge server has nothing to do with the maintenance of the 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. Therefore, the following list of steps will skip numbers. The missing steps are typically OK or DIAGNOSTIC messages that don't provide anything more than a simple, "I heard you." 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—for example, in a BENOTIFY message.
The first part of the message flow begins with the initial discussion of the Communicator client with the home pool server. The client logging in has to register with the pool that it is a member of. This tells the server where the client can be reached. Finally, note that the certificates that were painstakingly 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.contoso.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
A SUBSCRIBE method is used by the registered user agent 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. To terminate a SUBSCRIBE method, there is no corresponding UNSUBSCRIBE 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 is 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.contoso.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 very 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, as 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.contoso.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 (this example assumes that they do), they should be able to see that the other person is online. We've initiated and opened the Office Communicator client, signed into 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. (See Figure 7-9 on the next page.)
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.
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.contoso.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.contoso.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.contoso.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>
And 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.contoso.com:1061
Data: domain="contoso.com"
$$end_recordIn this set of actions, a couple of 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' client, and it also sends a 200/OK message back to Kim Akers. The 200/OK tells her client that you are now subscribed successfully on the Fabrikam.com domain, and much like the SUBSCRIBE just shown, it also indicates what the SUBSCRIBE contained.
The BENOTIFY, though, 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 this is what happened, and you now have 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_record
Steps 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 contoso.com and will be reflected in Kim's client, and to the state that John indicated when he first signed on.
In Step 5, John initiates a SUBSCRIBE that is destined for the Contoso.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 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, or end points:
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.contoso.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.
Why the verbosity of the messaging involved? Remember that SIP is a signaling protocol and, much like ships using a light to send Morse code back and forth, there is no way to know for sure that that the other end really did receive the message unless we respond. Almost everything has an OK associated with it. However, the ACK is unique to INVITE, as this is a three-way handshake process. Also, you should remember that SIP is pretty much 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.
Step 12—INFO sip:[email protected];opaque=user:epid:rcCqh5A6AVmnmbRnI5LzvwAA;gruu SIP/2.0
In the world of Office Communications Server 2007 instant messaging, it's this 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
Step 13—MESSAGE sip:[email protected];opaque=user:epid:IAnGIHUus1qSUt8ED60SDgAA;gruu SIP/2.0
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.contoso.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, the BYE method is sent by one person and the session is terminated. (Obviously, the other person can re-establish the communication, which involves most of the steps that we've reviewed in this section.)
Step 19—sip:[email protected];opaque=user:epid:IAnGIHUus1qSUt8ED60SDgAA;gruu SIP/2.0
Oddly, there really isn't all that much that 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.contoso.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:And the subsequent and final OK/200 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: -id002"" <sip:[email protected]>;epid=5d3080be61;tag=4c8535fa6e
CSeq: 3 BYE
<snip>