Tonino Filipovic

Microsoft Unified Communications

Office Communicator SIP Trace – Voice Call Flow

Office Communicator SIP Trace – Voice Call Flow

  • Comments 2
  • Likes

When using Office Communicator to place a voice call, you can use several different ways to establish a call:

  • clicking on a Communicator Call option next to the contact in your OC, thus using contact’s SIP URI to place a call
  • dialing E.164 number
  • dialing non-E.164 number and letting OCS “normalize” the number

Whatever way you choose to place a call, several OCS server-side components will be involved in call establishment, so let’s first shortly define what each of those components do:

  • Inbound Routing – handles incoming calls, taking into account user’s call-forwarding settings (e.g. if user configured the call forwarding settings so that incoming calls is forwarded to his/her cell phone, inbound routing would take care that the call is handled accordingly).
  • Translation Application – uses normalization rules based on user’s location profile to translate dialed number into a standard E.164 number. For complete information, let’s say that client also obtains normalization rules together with other configuration data through in-band provisioning process (more information in Jens Trier Rasmussen’s blog)
  • Outbound Routing – calls that are not destined to users hosted on OCS (when normalized number cannot be matched to any existing SIP URI) are transferred to Outbound Routing component that applies call authorization rules to callers and route the calls to PBX or PSTN.
  • User Services – handles several aspects of Office Communications Server (IM, Presence, Conferencing features) but is also very important for Enterprise voice functionality where it performs Reverse Number Lookup on the phone number of each incoming call and tries to match that number to a SIP URI. If a match is found the call is for an OCS-enabled user and stays within OCS environment, but if there is no match, the call has to be handled by Outbound Routing component that will route the call to PBX or PSTN.

Let’s see how SIP traces differ depending on which call scenario is used: SIP URI (Communicator Call), E.164 number or non-E.164 number.

Note: I am providing background information about SIP headers and parameters after first SIP INVITE message only, since majority of these headers are repeating in subsequent packets. New headers and parameters in later packets that are important for this article will be explained as well, where necessary. For more detailed information, though, please refer to RFCs and other articles often mentioned as references throughout this blog post.

Since analyzing all SIP packets in each call would be rather tiresome (and unnecessary) business, I will take three typical packets that can provide enough information to achieve this articles purpose: SIP INVITE, Progress Report and Session Progress messages.

 

Scenario 1: Calling basic[1] SIP URI (Communicator Call)

In this first example we’ll check what happens when you choose Communicator Call option when calling one of your contacts.

SIP INVITE

11/16/2009|16:52:21.441 2A0:F34 INFO :: Sending Packet - 200.1.1.20:443 (From Local Address: 200.1.1.201:2262) 5107 bytes:

11/16/2009|16:52:21.441 2A0:F34 INFO :: INVITE sip:izabelaf@uclab.org SIP/2.0

Via: SIP/2.0/TLS 200.1.1.201:2262

Max-Forwards: 70

From: <sip:marinof@uclab.org>;tag=fda796badd;epid=1488039028

To: <sip:izabelaf@uclab.org>

Call-ID: 0aee2d6389294d18af28ae9f219a3420

CSeq: 1 INVITE

Contact: <sip:marinof@uclab.org;opaque=user:epid:NFExHZ6mj1yDHREOYWtdYQAA;gruu>

User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

Ms-Conversation-ID: Acpm1MgQioYa3RnkRyeZp67T413HPw==

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

Supported: Replaces

Supported: 100rel

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

P-Preferred-Identity: <sip:marinof@uclab.org>, <tel:+38517654321>

Supported: ms-conf-invite

Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="628A7332", targetname="R2EE01.uclab.org", crand="c3ed0454", cnum="12", response="010000006e646964cf67ad685412cf8b"

Content-Type: multipart/alternative;boundary="----=_NextPart_000_0007_01CA66DD.2A245470"

Content-Length: 3968

------=_NextPart_000_0007_01CA66DD.2A245470

Content-Type: application/sdp

Content-Transfer-Encoding: 7bit

Content-Disposition: session; handling=optional; ms-proxy-2007fallback

Trace 1.1 – INVITE: Session setup using SIP URI of the called party (SDP offer (blue font) is truncated due to clarity)

 

The first packet shows the caller (sip:marinof@uclab.org) calling the other party using her SIP URI (sip:izabelaf@uclab.org). Since Request URI[2] already contains a SIP URI of a called party, there is no action whatsoever from the Translation Application side, nor from User Services side.

This means that there is no need to neither normalize non-E.164 number to E.164 (as there’s nothing to normalize), nor there is a need to match E.164 number to SIP-URI (as SIP URI is already there).

A little bit more detailed look at this first packet will reveal several interesting facts about establishing the call:

First, it shows session setup for which SIP uses an INVITE method[3]. Each session is uniquely identified by the From and To headers with tag and epid parameters and with the Call-ID[4].

As can be seen, the INVITE has been sent to (example) address 200.1.1.20 (which is an Access Edge server for uclab.org SIP domain) on a port dedicated for remote user access (443). The request is sent from the remote host which will be visible in one of the replies (ms-user-logon-data: RemoteUser), such as in Trace 1.2 – Progress Report.

“Contact” header contains URI registered by the user (sip:marinof@uclab.org) that provides contact information for other party in the call.

Supported” headers contain a list of supported options such as 100rel (ability to send provisional responses to INVITE messages in a reliable way), … and one very important option: ms-early-media.[5]

ms-early-media is a proprietary extension to SIP Supported header, and denotes client’s ability to receive an SDP answer in a provisional 18x message (apart from standard way through reliable 200 message). Effectively, this means that media exchange can start even before session is fully established.

“P-Preferred-Identity” header is generated by user agent when it needs to communicate an additional identity of the user (apart from the one in the From: header)[6]. This identity would later be used by trusted proxy to create P-Asserted-Identity value.

“Proxy-authorization” header was mentioned in more details in previous blog (Office Communicator SIP Trace Analysis – Registration ), so let’s just note here that in this particular session it shows that NTLM auth is used (Proxy-Authorization: NTLM), protection method used is authentication only, not integrity protection (qop=auth) and that response parameter caries client’s message signature.

Listing all headers found in INVITE message is far beyond the scope of this article, but two of these should not be omitted at least from short explanation: Via and Record-Route headers. Record-Route is added by proxies who decide to stay in the path of all responses to initial request, while Via header contains transport protocol used (SIP/2.0/TLS) and the client IP address:port combination.

Next part of this first packet (after Content-Length header) shows start of SDP Offer, but I removed it for the sake of clarity. If it weren’t removed, you’d see that there were two very similar SDP messages in this first INVITE message - to accommodate both OC 2007 (R1) and OC 2007 R2 clients.

First SDP message starting with ms-proxy-2007fallback parameter in Content-Disposition header is for R1 client while the second one is for R2 client.

Detailed SDP analysis is beyond the scope of this article, so if you want to dive deeper in SDP and media exchange negotiation itself, I’d highly recommend reading Bernd Ott’s blog at Communications Server Team Blog site. Apart from SDP details, Bernd provides excellent analysis of media traversal over NAT, which itself is very interesting reading.

The next analyzed trace will be the 101 Progress Report message sent by Front End server’s Inbound Routing component.

 

101 Progress Report

11/16/2009|16:52:21.612 2A0:F34 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2262) 697 bytes:

11/16/2009|16:52:21.612 2A0:F34 INFO :: SIP/2.0 101 Progress Report

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="0100000000000000BC4976EB5412CF8B", srand="7756C6C0", snum="14", opaque="628A7332", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Content-Length: 0

Via: SIP/2.0/TLS 200.1.1.201:2262;ms-received-port=2262;ms-received-cid=2D00

From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=fda796badd;epid=1488039028

To: <sip:izabelaf@uclab.org>

Call-ID: 0aee2d6389294d18af28ae9f219a3420

CSeq: 1 INVITE

ms-diagnostics: 13004;reason="Request was proxied to one or more registered endpoints";source="R2EE01.uclab.org";appName="InboundRouting"

Server: InboundRouting/3.5.0.0

Trace 1.2 – Progress Report

 

ms-diagnostics[7] header in Progress Report trace contains some interesting information - it shows that Inbound Routing application will proxy the call to one or more called party’s registered SIP endpoints. In case of more than one registered endpoint for the called party, the call would be forked to all registered endpoints. Server header found in Progress Report does not denote physical server, but rather server-side application responsible for handling client’s request.

The next interesting packet (Trace 1.3) shows Session Progress in which you can see two Record-Route headers (defined earlier in the text) with values of Access Proxy server (sip:sip.uclab.org:443) and OCS pool (sip:pool01.uclab.org:5061). Please pay attention to ms-fe parameter found in first Record-Route header value (ms-fe=r2ee01.uclab.org). When SIP server is a member of a pool of servers that share the same FQDN (in this case pool01.uclab.org), ms-fe parameter enables particular member of the pool (that is working on the request), to put its own, unique FQDN (ms-fe=r2ee01.uclab.org) and denote the particular member of the pool that should stay in the path of future SIP message exchanges.

183 Session Progress

11/16/2009|16:52:22.443 2A0:F34 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2262) 2585 bytes:

11/16/2009|16:52:22.443 2A0:F34 INFO :: SIP/2.0 183 Session Progress

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="01000000000000001DC9DAC65412CF8B", srand="77BAA84A", snum="16", opaque="628A7332", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Via: SIP/2.0/TLS 200.1.1.201:2262;ms-received-port=2262;ms-received-cid=2D00

From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=fda796badd;epid=1488039028

To: <sip:izabelaf@uclab.org>;epid=2798f0b3cc;tag=5e5e12af1a

Call-ID: 0aee2d6389294d18af28ae9f219a3420

CSeq: 1 INVITE

Record-Route: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F:T:Eu;lr;received=172.31.255.222;ms-received-cid=2701>

Contact: <sip:izabelaf@uclab.org;opaque=user:epid:uozeqPgOuFOVd0DaRpeFCgAA;gruu>

User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2)

Require: 100rel

RSeq: 1

Content-Type: application/sdp

Content-Length: 1520

Record-Route: <sip:sip.uclab.org:443;transport=tls;opaque=state:Ci.R2d00;lr;ms-route-sig=gadu3AbEKriSVtRh1_ODE_CC6EuF7pPgc70lwmrQAA>

v=0

o=- 0 0 IN IP4 172.31.255.71

s=session

c=IN IP4 172.31.255.71

b=CT:99980

t=0 0

m=audio 2879 RTP/SAVP 114 111 115 8 0 97 13 118 101

a=ice-ufrag:hfAS

a=ice-pwd:MNL10SujMvycj08p4UH/lP02

a=candidate:1 1 UDP 2130706431 172.31.255.71 2879 typ host

a=candidate:1 2 UDP 2130705918 172.31.255.71 20457 typ host

Trace 1.3 - Session Progress carrying SDP Answer

 

The Session Progress message shows that called party (sip:izabelaf@uclab.org) has registered OC Phone endpoint (User-Agent: CPE/3.5.6907.0 OCPhone/3.5.6907.0 (Office Communicator Phone 2007 R2) . If called party has registered more than one SIP endpoint, the caller would receive multiple 183 Session Progress messages, but in that case tag and epid parameters in To: header would carry different values in these separate messages (To-tag and epid parameters uniquely identify each registered endpoint). You can also see an answer to initial SDP Offer found in INVITE message (truncated due to clarity). This is where R2 client differs from R1 in which you could find an SDP Answer only later in 200 OK response (as there was no support for early media in previous client version[8]).

 

Scenario 2: Calling E.164 number

Following traces show how session setup differs when user dials using E.164 number. In the first place, you’ll see some additional server components involved as this call has destination outside of OCS environment (either on other PBX or PSTN).

SIP INVITE

11/16/2009|17:02:04.249 2A0:F34 INFO :: Sending Packet - 200.1.1.20:443 (From Local Address: 200.1.1.201:2262) 5137 bytes:

11/16/2009|17:02:04.249 2A0:F34 INFO :: INVITE sip:+38511234567@uclab.org;user=phone SIP/2.0

Via: SIP/2.0/TLS 200.1.1.201:2262

Max-Forwards: 70

From: <sip:marinof@uclab.org>;tag=d089e797cf;epid=1488039028

To: <sip:+38511234567@uclab.org;user=phone>

Call-ID: 036f540493ef4d089dff7c50d197b43f

CSeq: 1 INVITE

Contact: <sip:marinof@uclab.org;opaque=user:epid:NFExHZ6mj1yDHREOYWtdYQAA;gruu>

User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

Ms-Conversation-ID: Acpm1iN/R7sNneRNT8eC9BppFFWX+w==

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

Supported: Replaces

Supported: 100rel

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

P-Preferred-Identity: <sip:marinof@uclab.org>, <tel:+38517654321>

Supported: ms-conf-invite

Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="628A7332", targetname="R2EE01.uclab.org", crand="2d80635e", cnum="46", response="010000006e646964031f26bd5412cf8b"

Content-Type: multipart/alternative;boundary="----=_NextPart_000_0016_01CA66DE.85874C90"

Content-Length: 3968

------=_NextPart_000_0016_01CA66DE.85874C90

Content-Type: application/sdp

Content-Transfer-Encoding: 7bit

Content-Disposition: session; handling=optional; ms-proxy-2007fallback

v=0

o=- 0 0 IN IP4 200.1.1.20

s=session

c=IN IP4 200.1.1.20

b=CT:99980

t=0 0

m=audio 52828 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101

k=base64:8nz2U+Sr7tkJOyxCVKRXT1JoEwganb5OVW5QFs5v40hiBx3fuyzPa+oHcHTH

a=candidate:Y/dexvxW+WxmsamABmy6olEMpPbYL4muLNDd+Hb/BHs 1 ei885sgdxFjptCgFT+bAJg UDP 0.860 200.1.1.201 50007

a=candidate:Y/dexvxW+WxmsamABmy6olEMpPbYL4muLNDd+Hb/BHs 2 ei885sgdxFjptCgFT+bAJg UDP 0.860 200.1.1.201 50002

Trace 2.1 – INVITE showing user=phone parameter

 

It’s important to stress the significant difference in Request URI compared to Scenario 1 :

INVITE sip:+38511234567@uclab.org;user=phone SIP/2.0.

Apart from visible difference in first part of SIP URI (phone number instead of user alias), a new parameter user=phone is added which denotes that SIP URI is in phone number format. Again, an SDP details follow (and again truncated significantly due to clarity)

101 Progress Report

The second trace shows Progress Report which again differs from the equivalent packet in Scenario 1.

11/16/2009|17:02:04.470 2A0:F34 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2262) 868 bytes:

11/16/2009|17:02:04.470 2A0:F34 INFO :: SIP/2.0 101 Progress Report

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="0100000000000000517441485412CF8B", srand="7EBD2724", snum="55", opaque="628A7332", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Content-Length: 0

Via: SIP/2.0/TLS 200.1.1.201:2262;ms-received-port=2262;ms-received-cid=2D00

From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=d089e797cf;epid=1488039028

To: <sip:+38511234567@uclab.org;user=phone>

Call-ID: 036f540493ef4d089dff7c50d197b43f

CSeq: 1 INVITE

ms-diagnostics: 12006;reason="Trying next hop";source="R2EE01.uclab.org";PhoneUsage="CN={AB77AE74-F9B1-480F-B7CD-79792BC13D87},CN=Phone Route Usages,CN=RTC Service,CN=Services,CN=Configuration,DC=uclab,DC=org";PhoneRoute="Local Calls";Gateway="R2MS01.uclab.org:5061";appName="OutboundRouting"

Server: OutboundRouting/3.5.0.0

Trace 2.2 – Progress Report

ms-diagnostics header value in 101 Progress Report this time shows that another server side component is involved: Outbound Routing. The reason behind involvement of Outbound Routing component is rather simple: E.164 number of the called party (+38511234567) could not be matched to any existing SIP URI, which shows that the called party is either on a PBX system or PSTN, so the call has to be routed out of OCS system to the next hop using Local Calls route (PhoneRoute="Local Calls";Gateway="R2MS01.uclab.org:5061"). Just a note that apart from finding the best route for the call, Outbound Routing also performs a call authorization (in a nutshell, it is matching normalized number and caller’s Voice Policy phone usages to the number pattern and phone usages in available routes).

 

183 Session Progress

11/16/2009|17:02:04.690 2A0:F34 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2262) 2650 bytes:

11/16/2009|17:02:04.690 2A0:F34 INFO :: SIP/2.0 183 Session Progress

ms-user-logon-data: RemoteUser

Via: SIP/2.0/TLS 200.1.1.201:2262;ms-received-port=2262;ms-received-cid=2D00

Authentication-Info: NTLM rspauth="0100000000000000260310965412CF8B", srand="CDB978E7", snum="56", opaque="628A7332", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

FROM: "Marino Filipovic"<sip:marinof@uclab.org>;tag=d089e797cf;epid=1488039028

TO: <sip:+38511234567@uclab.org;user=phone>;tag=2fe83c9f;epid=B6EE6ACB83

CSEQ: 1 INVITE

CALL-ID: 036f540493ef4d089dff7c50d197b43f

RECORD-ROUTE: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F;lr;received=172.31.255.222;ms-received-cid=2701>

CONTACT: <sip:R2MS01.uclab.org@uclab.org;gruu;opaque=srvr:MediationServer:XDQqnDzOpESpnFD0MajmKgAA>;isGateway

CONTENT-LENGTH: 1558

SUPPORTED: gruu-10

CONTENT-TYPE: application/sdp

ALLOW: UPDATE

REQUIRE: 100rel

SERVER: RTCC/3.5.0.0 MediationServer

Rseq: 1

Record-Route: <sip:sip.uclab.org:443;transport=tls;opaque=state:Ci.R2d00;lr;ms-route-sig=gasAR62MgLINIzHBRWokPQinSiu77VVVbz0lwmrQAA>

v=0

o=- 0 0 IN IP4 172.31.255.223

s=session

c=IN IP4 172.31.255.223

b=CT:1000

t=0 0

m=audio 62724 RTP/SAVP 0 8 115 13 118 97 101

c=IN IP4 172.31.255.247

a=rtcp:60177

a=ice-ufrag:xVRU

a=ice-pwd:oI+0a7+PQL8RD5eS+xaTrDsJ

a=candidate:1 1 UDP 2130706431 172.31.255.247 62724 typ host

a=candidate:1 2 UDP 2130705918 172.31.255.247 60177 typ host

Trace 2.3 –Session Progress

 

The 183 Session Progress packet is sent from Mediation Server that in turn sends an SDP Answer, sending its own candidates to the client.

In this particular case where remote user places a call to PSTN, the Mediation server acts as an ICE client. Although media connectivity and firewall traversal is completely different topic out of this article’s scope, let’s just be aware that Mediation Server not only does codec translation and encapsulation of SIP into TLS, but it also acts as an ICE client for calls where one party is outside of organization (remote user) and the other one is on PSTN or PBX. For such call to be established at all, it’s necessary for media to traverse firewall, AV Edge, and Mediation server, before it’s finally sent to the gateway and PSTN or PBX. To establish the most optimal media path along this way, it’s necessary to use ICE and Mediation server thus acts as an ICE client in such call scenarios.

One more detail worth mentioning in this trace is the isGateway parameter of the Contact header:

CONTACT: <sip:R2MS01.uclab.org@uclab.org;gruu;opaque=srvr:MediationServer:XDQqnDzOpESpnFD0MajmKgAA>;isGateway

A SIP User Agent stamping isGateway parameter in the Contact header denotes that it has a role of the gateway.

 

Scenario 3: Calling non-E.164 number

The third scenario happens in situations when user types in the number that is not in E.164 format and the client cannot normalize the number using existing rules. [9]

SIP INVITE

11/17/2009|18:22:36.901 E54:F68 INFO :: Sending Packet - 200.1.1.20:443 (From Local Address: 200.1.1.201:2389) 5188 bytes:

11/17/2009|18:22:36.901 E54:F68 INFO :: INVITE sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone SIP/2.0

Via: SIP/2.0/TLS 200.1.1.201:2389

Max-Forwards: 70

From: <sip:marinof@uclab.org>;tag=0c0ef918e6;epid=1488039028

To: <sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone>

Call-ID: bcd9cff8600c4b2487845f5ae211f7c6

CSeq: 2 INVITE

Contact: <sip:marinof@uclab.org;opaque=user:epid:NFExHZ6mj1yDHREOYWtdYQAA;gruu>

User-Agent: UCCAPI/3.5.6907.0 OC/3.5.6907.0 (Microsoft Office Communicator 2007 R2)

Ms-Conversation-ID: Acpnqo4mdWwkauuDSkmzOozY9Es0ow==

Supported: timer

Supported: histinfo

Supported: ms-safe-transfer

Supported: ms-sender

Supported: ms-early-media

Supported: Replaces

Supported: 100rel

ms-keep-alive: UAC;hop-hop=yes

Allow: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS

P-Preferred-Identity: <sip:marinof@uclab.org>, <tel:+38517654321>

Supported: ms-conf-invite

Proxy-Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="5C3ADF72", targetname="R2EE01.uclab.org", crand="f8c12e13", cnum="2", response="010000006e64696432ff475bdb3f8ba6"

Content-Type: multipart/alternative;boundary="----=_NextPart_000_003F_01CA67B2.F06D3950"

Content-Length: 3968

------=_NextPart_000_003F_01CA67B2.F06D3950

Content-Type: application/sdp

Content-Transfer-Encoding: 7bit

Content-Disposition: session; handling=optional; ms-proxy-2007fallback

v=0

o=- 0 0 IN IP4 200.1.1.20

s=session

c=IN IP4 200.1.1.20

b=CT:99980

t=0 0

m=audio 53192 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101

k=base64:zNM45WUMx3rM0ia1GYK/7sjrazYa0XKuCtvlw40qdhd+WUD8fy3JmhylaxHh

a=candidate:kp5leWkR7rFrrXLbl2zQ+XD/6kw/e9Ho/onLrkYUg54 1 6IWEArE1V0Pud+C/oHj+iA UDP 0.890 200.1.1.201 50018

a=candidate:kp5leWkR7rFrrXLbl2zQ+XD/6kw/e9Ho/onLrkYUg54 2 6IWEArE1V0Pud+C/oHj+iA UDP 0.890 200.1.1.201 50007

Trace 3.1 – INVITE showing Phone-context parameter

 

The new header, seen for the first time in this scenario, is Phone-Context header (INVITE sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone SIP/2.0).

Phone-Context header can be found when Request URI contains neither basic SIP URI, nor phone number in E.164 format. The value of Phone-Context header is the name of user’s Location Profile (zagreb.uclab.org) where location profile contains all necessary normalization rules to translate user-entered phone number. More details on this visible from next Progress Report packet, sent by Translation Service.

101 Progress Report (1)

11/17/2009|18:22:39.014 E54:F68 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2389) 912 bytes:

11/17/2009|18:22:39.014 E54:F68 INFO :: SIP/2.0 101 Progress Report

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="0100000000000000106D7D7BDB3F8BA6", srand="70653AFF", snum="10", opaque="5C3ADF72", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Content-Length: 0

Via: SIP/2.0/TLS 200.1.1.201:2389;ms-received-port=2389;ms-received-cid=4000

From: <sip:marinof@uclab.org>;tag=0c0ef918e6;epid=1488039028

To: <sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone>

Call-ID: bcd9cff8600c4b2487845f5ae211f7c6

CSeq: 2 INVITE

ms-diagnostics: 14011;reason="Called Number translated";source="R2EE01.uclab.org";RuleName="3test";RuleDN="CN={24428855-3EEA-42DC-A6EC-A2CD2F3F43D1},CN=Location Normalization Rules,CN=RTC Service,CN=Services,CN=Configuration,DC=uclab,DC=org";CalledNumber="3123456";TranslatedNumber="+38535123456";appName="TranslationService"

Server: TranslationService/3.5.0.0

Trace 3.2 – Progress Report (first packet)

 

The first Progress Report packet sent from Translation Service (Server: TranslationService/3.5.0.0) holds an interesting data in ms-diagnostics header carrying information about normalization rule used  to translate dialed number (RuleName=”3test”), as well as dialed (CalledNumber=”3123456”) and translated number (TranslatedNumber=”+38535123456”).

 

101 Progress Report (2)

11/17/2009|18:22:39.154 E54:F68 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2389) 897 bytes:

11/17/2009|18:22:39.154 E54:F68 INFO :: SIP/2.0 101 Progress Report

ms-user-logon-data: RemoteUser

Authentication-Info: NTLM rspauth="01000000000000003A15F11FDB3F8BA6", srand="38D4C7E0", snum="11", opaque="5C3ADF72", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

Content-Length: 0

Via: SIP/2.0/TLS 200.1.1.201:2389;ms-received-port=2389;ms-received-cid=4000

From: "Marino Filipovic"<sip:marinof@uclab.org>;tag=0c0ef918e6;epid=1488039028

To: <sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone>

Call-ID: bcd9cff8600c4b2487845f5ae211f7c6

CSeq: 2 INVITE

ms-diagnostics: 12006;reason="Trying next hop";source="R2EE01.uclab.org";PhoneUsage="CN={D6912478-0BBC-4A6B-83F6-01D79BD7E126},CN=Phone Route Usages,CN=RTC Service,CN=Services,CN=Configuration,DC=uclab,DC=org";PhoneRoute="National Calls";Gateway="R2MS01.uclab.org:5061";appName="OutboundRouting"

Server: OutboundRouting/3.5.0.0

Trace 3.3 – Progress Report (second packet)

 

The second Progress Report packet is sent from another server side application: Outbound Routing (Server: OutboundRouting/3.5.0.0). The number normalized by Translation Service (as explained in Trace 3.2) could not be matched to existing SIP URI, and thus the call has to be routed out of OCS environment via Med.Server/gateway using the National Calls route (PhoneRoute="National Calls";Gateway="R2MS01.uclab.org:5061"). Again, the choice of the route and appropriate gateway has come as a result of previously mentioned procedure (matching normalized number and caller’s Voice Policy phone usages to the number pattern and phone usages in available routes)

 

183 Session Progress

11/17/2009|18:22:39.435 E54:F68 INFO :: Data Received - 200.1.1.20:443 (To Local Address: 200.1.1.201:2389) 2678 bytes:

11/17/2009|18:22:39.435 E54:F68 INFO :: SIP/2.0 183 Session Progress

ms-user-logon-data: RemoteUser

Via: SIP/2.0/TLS 200.1.1.201:2389;ms-received-port=2389;ms-received-cid=4000

Authentication-Info: NTLM rspauth="0100000000000000A6E772DCDB3F8BA6", srand="60A1AF0C", snum="12", opaque="5C3ADF72", qop="auth", targetname="R2EE01.uclab.org", realm="SIP Communications Service"

FROM: "Marino Filipovic"<sip:marinof@uclab.org>;tag=0c0ef918e6;epid=1488039028

TO: <sip:3123456;phone-context=zagreb.uclab.org@uclab.org;user=phone>;tag=753a4cf29d;epid=B6EE6ACB83

CSEQ: 2 INVITE

CALL-ID: bcd9cff8600c4b2487845f5ae211f7c6

RECORD-ROUTE: <sip:pool01.uclab.org:5061;transport=tls;ms-fe=R2EE01.uclab.org;opaque=state:F;lr;received=172.31.255.222;ms-received-cid=4101>

CONTACT: <sip:R2MS01.uclab.org@uclab.org;gruu;opaque=srvr:MediationServer:XDQqnDzOpESpnFD0MajmKgAA>;isGateway

CONTENT-LENGTH: 1558

SUPPORTED: gruu-10

CONTENT-TYPE: application/sdp

ALLOW: UPDATE

REQUIRE: 100rel

SERVER: RTCC/3.5.0.0 MediationServer

Rseq: 1

Record-Route: <sip:sip.uclab.org:443;transport=tls;opaque=state:Ci.R4000;lr;ms-route-sig=halHDFb5tb_P1j5pyPPGNCZq-kEkaR3G_J0lwmrQAA>

v=0

o=- 0 0 IN IP4 172.31.255.223

s=session

c=IN IP4 172.31.255.223

b=CT:1000

t=0 0

m=audio 61508 RTP/SAVP 0 8 115 13 118 97 101

c=IN IP4 172.31.255.247

a=rtcp:60865

a=ice-ufrag:jrbL

a=ice-pwd:vmjJgl/BqZr0BfHdGG8+m5Lr

a=candidate:1 1 UDP 2130706431 172.31.255.247 61508 typ host

a=candidate:1 2 UDP 2130705918 172.31.255.247 60865 typ host

a=candidate:2 1 UDP 2130705919 172.31.255.223 63845 typ host

a=candidate:2 2 UDP 2130705406 172.31.255.223 63260 typ host

Trace 3.4 – Session Progress

 

Not much to comment in Session Progress packet, as it is also consistent with the previous packets in this scenario.

Since the normalized number has destination on PSTN, the Mediation server acts as ICE client and sends an SDP answer with its candidates back to originating client to negotiate the optimal media path. Again, for more information about firewall traversal of media, please refer to very detailed blog How Communicator Uses SDP and ICE To Establish a Media Channel created by Bernd Ott.


[1] SIP URIs can be found in several formats: sip:name@domain.com (basic SIP URI), sip:+12345678@domain.com (SIP URI with phone number), sip:name@1.2.3.4 (SIP URI with IP address) and several other formats.

[2] According to RFC 3261, initial Request URI is set to the value of URI in the To: field (except for REGISTER request).

[3] SIP session setup is a three-way handshake process – INVITE/OK/ACK for a success, or INVITE/4XX or 5xx or 6xx/ACK in case of a failure. INVITE is the only SIP method that is in a form of three way handshake, as all other SIP requests are in the form of Request/200 or Request/4xx or 5xx or 6xx for a failure. Several provisional responses (1xx) can be seen between INVITE and final 200 OK (Trying, Progress Report, Session Progress), and we’ll tackle these responses later through SIP traces.

[4] The From-tag parameter is assigned when the INVITE request is sent out while the To-tag is added by the remote party when answering INVITE request

[5] According to Early Media and Ringing Tone Generation in the Session Initiation Protocol , early media “refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user”.

[6] For more details on P-Preferred-Identity and P-Asserted-Identity headers, please see RFC 3325 - Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks

[7] ms-diagnostics header is added by SIP server to indicate an error and/or provide a troubleshooting information that can be helpful in resolving the error. Since values of this header can contain information that is private to the company, it should be removed when SIP responses are leaving the enterprise boundary.

[8] Lack of support for early media in previous client version could sometimes lead to initial greeting not being heard.

[9] Normally, the client itself will normalize the number immediately as user is typing the number in OC (as client receives all normalization rules through in-band provisioning process) but in rare cases (such as when new normalization rule is added and client still didn’t refresh the information), the server-side Translation Application will be involved, as in example above.

Comments
  • Good info with explanations. What does the Required 100rel statments indicate?

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment