Session Initiation Protocol (SIP) Deep Dive
Version 1.0 (29/April/2024)
Abdul Jaseem
UC Solution Architect
(Former Technical Consulting Engineer at Cisco TAC)
CCIE #59174, Azure Administrator, AWS SAA,
vmware VCP DCV, Kubernetes Administrator, ACE MCNA,
Teams Certified Voice Engineer, DevNet Professional, CCNP
Collaboration, CCNP DC, CCNP Ent.
LinkedIn: [Link]
YouTube: [Link]
Contents
Session Initiation Protocol - SIP ...................................................................................................................................................... 3
SIP Call Flows .......................................................................................................................................................................................... 4
SIP Early Offer Call Flow ................................................................................................................................................................. 4
SIP Delayed Offer Call Flow .......................................................................................................................................................... 5
SIP Early Media Call Flow ............................................................................................................................................................... 6
SIP Request or Methods ..................................................................................................................................................................... 7
SIP Responses ....................................................................................................................................................................................... 11
Microsoft Teams Direct Routing with all SBCs (AudioCodes, Ribbon, CUBE, AnyNode SBCs) .............................. 15
About the Author ................................................................................................................................................................................ 17
2
Session Initiation Protocol - SIP
• It's an open standard peer-to-peer communication protocol used for initiating, maintaining, and
terminating real-time sessions, such as voice and video calls over IP networks.
SIP is an application-layer protocol, part of the TCP/IP protocol suite, and it's widely used in VoIP (Voice over
Internet Protocol) and unified communications systems.
• Open standard peer-to-peer communications protocol for Voice and Video Call
• It uses a TCP / UDP 5060 port number and TLS 5061 for Secure SIP (SSIP) by default.
• Internet Engineering Task Force (IETF) developed SIP as an alternative to H.323
• SIP is a peer-to-peer protocol where internet endpoints (User Agents) initiate sessions, similar to
H.323
• SIP uses SDP (Session Description Protocol) to exchange capabilities (Media IP, Port, Codec, DTMF
Relay, etc.)
• Internet Telephony Service Provider (ITSP) uses SIP as their standard
Sample SIP Log can be downloaded from:
[Link]
3
SIP Call Flows
SIP Early Offer Call Flow
Teams Phone System SIP SIP
SBC
PSTN Carrier
INVITE (SDP)
100 Trying
INVITE (SDP)
Transaction 1
100 Trying
180 Ringing
180 Ringing
200 OK (SDP)
200 OK (SDP)
ACK
2
ACK
RTP Media RTP Media
BYE
Transaction 3
BYE
200 OK
200 OK
• Originator sends the offer SDP in initial INVITE
• Remote party answer SDP exchanged in the 200 OK response
4
SIP Delayed Offer Call Flow
Teams Phone System SIP SIP
SBC
PSTN Carrier
INVITE
100 Trying
INVITE
Transaction 1
100 Trying
180 Ringing
180 Ringing
200 OK (SDP)
200 OK (SDP)
ACK (SDP)
2
ACK (SDP)
RTP Media RTP Media
BYE
Transaction 3
BYE
200 OK
200 OK
• Remote party sends the offer SDP in 200 OK message
• Originator sends the answer SDP in the ACK message
5
SIP Early Media Call Flow
Teams Phone System SIP SIP
SBC
PSTN Carrier
INVITE (SDP)
100 Trying
INVITE (SDP)
100 Trying
183 Session Progress (SDP)
183 Session Progress (SDP)
PRACK
PRACK
200 OK (for PRACK)
200 OK (for PRACK)
RTP Early Media RTP Early Media
200 OK (SDP) (for INVITE)
200 OK (SDP) (for INVITE)
ACK
ACK
RTP Media RTP Media
BYE
BYE
200 OK
200 OK
• Remote party sends the answer SDP in 183 Session Progress message
• Originator sends the PRACK for the 183 Session Progress
6
SIP Request or Methods
SIP Request or Methods are the SIP messages that takes an action. Each method serves a specific purpose
in initiating, managing, and terminating SIP sessions, facilitating seamless communication over IP networks.
E.g. INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS, INFO and UPDATE are called SIP Requests or Methods.
1. INVITE: Used to establish media sessions between user agents. When a user wants to start a call,
they send an INVITE request. If 200 OK is received from the other party, then the originator sends an
ACK message for a successful session. In the below example, we have taken the INVITE message that
came from Microsoft Teams Side to an SBC.
INVITE sip:+919495860708@[Link];user=phone;transport=tls SIP/2.0
>> SIP URI
FROM: "Tom
Cruise"<sip:+12148883759@[Link];user=phone>;tag=530037cdf3154211838df2
c946301eb5
>> Originator
TO: <sip:+919495860708@[Link];user=phone>
>> Destination
CSEQ: 1 INVITE
>> Call Sequence Number: Each SIP Request in same dialogue follows same number, here it is 1
CALL-ID: bec174eecf47582ba2613ba0008d04bc
>> Per call-leg Unique identifier
MAX-FORWARDS: 70
>> Maximum number of hops that a SIP request can traverse before being discarded. Decrement 1
at every hop. It helps to avoid loops
VIA: SIP/2.0/TLS [Link]:5061;branch=z9hG4bK8f0ecbd0
>> It provides information about the path that the SIP request has taken and helps ensure that
responses are sent back along the same path. In this example, Responses has to go to
[Link].
RECORD-ROUTE: <sip:[Link];transport=tls;lr>
>> Provides the details about the path taken by the message (similar to VIA), but RECORD-ROUTE
used to route the SIP Requests/Methods
CONTACT: <sip:[Link];x-i=9a568952-1b32-48df-9cf6-
c21a7d31522a;x-c=bec174eecf47582ba2613ba0008d04bc/d/8/5b104bfafeed4474a2c7baa7a8c8ad5e>
>> Details about the sender in the originating SIP Server. Specifies how to contact the
originator
CONTENT-LENGTH: 1109
>> Size of the message body in bytes (Typically the SDP Size)
MIN-SE: 300
>> Minimum Session Expiration time used to avoid frequent refresh requests. After 300 Sec (5
Minutes) there will be a refresh mechanism.
SUPPORTED: histinfo,timer
>> Features or functionalities it is capable of handling
USER-AGENT: [Link] v.2024.3.27.6 [Link].9
7
>> Application responsible for generating the SIP message
CONTENT-TYPE: application/sdp
>> Type of content contained in the message body
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
>> Actions supported by the SIP entity that receives the message
SESSION-EXPIRES: 3600
>> Maximum amount of time, in seconds, that the session can last before it expires. If no
refresh request is received within this time, the session is considered ended.
v=0 >> SDP Vertion
o=- 210233 0 IN IP4 [Link]
s=session
c=IN IP4 [Link] >> IP Address where the other party sends media
b=CT:10000000
t=0 0
m=audio 51422 RTP/SAVP 104 9 103 111 18 0 8 97 101 13 118 >> Media Port, Codecs, DTMF Relay
c=IN IP4 [Link] >> IP Address where the other party sends media
a=rtcp:51423
a=ice-ufrag:6oMa
a=ice-pwd:krlR4f2YJs8G59vu2+xVOFw5
a=rtcp-mux
a=candidate:1 1 UDP 2130706431 [Link] 51422 typ srflx raddr [Link] rport 51422
a=candidate:1 2 UDP 2130705918 [Link] 51423 typ srflx raddr [Link] rport 51423
a=candidate:2 1 tcp-act 2121006078 [Link] 49152 typ srflx raddr [Link] rport
49152
a=candidate:2 2 tcp-act 2121006078 [Link] 49152 typ srflx raddr [Link] rport
49152
a=label:main-audio
a=mid:1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:DURdyQIpmQXkJNh6pgjer4fO2ZaL7wE2XW+YRZmR|2^31
a=sendrecv
a=rtpmap:104 SILK/16000 >> SILK codec with a sampling rate of 16 kHz
a=rtpmap:9 G722/8000 >> G722 codec with a sampling rate of 8 kHz
a=rtpmap:103 SILK/8000 >> SILK codec with a sampling rate of 8 kHz
a=rtpmap:111 SIREN/16000 >> SIREN codec with a sampling rate of 16 kHz
a=fmtp:111 bitrate=16000
a=rtpmap:18 G729/8000 >> G729 codec with a sampling rate of 8 kHz
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000 >> G711 mu-law codec with a sampling rate of 8 kHz
a=rtpmap:8 PCMA/8000 >> G711 A-law codec with a sampling rate of 8 kHz
a=rtpmap:97 RED/8000 >> Robust Header Compression (RED) codec with a sampling rate of 8 kHz
a=rtpmap:101 telephone-event/8000 >> In-band DTMF signaling with a sampling rate of 8 kHz
a=fmtp:101 0-16
a=rtpmap:13 CN/8000 >> Comfort Noise codec with a sampling rate of 8 kHz
a=rtpmap:118 CN/16000 >> Comfort Noise codec with a sampling rate of 16 kHz
a=ptime:20 >> Duration of each media packet will be 20 milliseconds
8
2. ACK: Used to acknowledge final responses to INVITE requests. Final response to INVITE request will
be 200 OK. Final responses to all other requests are never acknowledged. Final responses are defined
as 2XX, 3XX, 4XX, 5XX, or 6XX class responses. The CSeq number is never incremented for an ACK
ACK sip:[Link];transport=tls SIP/2.0 >> ACK targeting to the URI
FROM: “Tom
Cruise”<sip:+12148883759@[Link];user=phone>;tag=530037cdf3154211838df2
c946301eb5
TO: <sip:+919495860708@[Link]>;user=phone;tag=93984964_c3356d0b_4550fce5-9694-
4a77-9dee-7b21b5efd33d
CSEQ: 1 ACK >> New dialogue
CALL-ID: bec174eecf47582ba2613ba0008d04bc
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS [Link]:5061;branch=z9hG4bK59780672
CONTACT: <sip:[Link];x-i=9a568952-1b32-48df-9cf6-
c21a7d31522a;x-c=bec174eecf47582ba2613ba0008d04bc/d/8/5b104bfafeed4474a2c7baa7a8c8ad5e>
CONTENT-LENGTH: 0
USER-AGENT: [Link] v.2024.3.27.6 [Link].9
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
3. BYE: used to terminate an established media session. A session is considered as established if an
INVITE has received a success class response (2XX) and ACK has been sent. A BYE is sent only by the
user agents participating in the session.
BYE sip:[Link]:5060 SIP/2.0
Via: SIP/2.0/TLS [Link]:5061;alias;branch=z9hG4bKac696993654
Max-Forwards: 69
From: "Tom Cruise" <sip:+12148883759@[Link];user=phone>;tag=1c870637020
To: <sip:+919495860708@[Link];user=phone>;tag=93984964_c3356d0b_4550fce5-
9694-4a77-9dee-7b21b5efd33d
Call-ID: 500710583293202415356@[Link]
CSeq: 3 BYE >> New dialogue
Route: <sip:[Link]:5061;transport=tls;r2=on;lr;twnat=sip:[Link]:52090>
Route: <sip:[Link]:5060;r2=on;lr;twnat=sip:[Link]:52090>
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY
User-Agent: Mediant SW/v.7.20A.258.271
Reason: Q.850 ;cause=16 ;text="9a568952-1b32-48df-9cf6-c21a7d31522a;LocalUserInitiated"
Content-Length: 0
4. CANCEL: used to terminate pending call attempts. When originator disconnects the call before the
call connects, we will see CANCEL instead of BYE message.
CANCEL sip:+919495860708@[Link] SIP/2.0
Via: SIP/2.0/TCP [Link]:5060;branch=z9hG4bK23E59
From: "11001 - Abdul Jaseem" <sip:+12176411001@[Link]>;tag=BCD6D0-6A2
To: <sip:+919495860708@[Link]>
Date: Mon, 19 Feb 2024 19:39:40 GMT
Call-ID: 753F5BC0-CE9511EE-826CB8C9-69752C6@[Link]
CSeq: 1 CANCEL
Max-Forwards: 70
Timestamp: 1708371586
Reason: Q.850;cause=16
Session-ID: cb9aa2ca266f438a9fbd84fc46aa2493;remote=00000000000000000000000000000000
Content-Length: 0
9
5. OPTIONS: Used to discover the availability of user agents. The response to the request lists the
capabilities of the user agent or server. It works as a Keepalive mechanism.
OPTIONS sip:[Link]:5060 SIP/2.0
Via: SIP/2.0/TCP [Link]:5060;branch=z9hG4bK972d8d7fe5
From: <sip:[Link]>;tag=539356525
To: <sip:[Link]>
Date: Mon, 19 Feb 2024 19:43:28 GMT
Call-ID: 25e33580-1ef1ed62-8e-1f0010ac@[Link]
User-Agent: Cisco-CUCM12.5
CSeq: 1 OPTIONS
Contact: <sip:[Link]:5060;transport=tcp>
Max-Forwards: 0
Content-Length: 0
10
SIP Responses
• INFORMATIONAL (1XX): The informational class of responses 1XX are end-to-end responses and
used to indicate call progress. Informational responses
o 100 TRYING: This special case response is only a hop-by-hop request. It is never forwarded
o 180 Ringing: This response is used to indicate that the user agent has received the INVITE and
that alerting has taken place
o 182 Call Queued: This response indicates that the INVITE has been received and will be
processed in a queue.
o 183 Session Progress: Indicates information about the session's progress. 183 is an end-to-end
response. A typical use of this response is to allow a UAC to hear ring tone, busy tone, or a
recorded announcement. 183 session progress can have SDP and PRACK used to acknowledge
it. A one-way media connection is established from the calling party’s telephone switch to the
called party’s telephone switch in the PSTN prior to the call being answered
• SUCCESS (2XX): Success class responses indicate that the request has succeeded or has been
accepted
o 200 OK: Used to accept a session invitation, sometimes it has a body with media properties
(SDP) of the UAS (called party)
o 202 Accepted: Response indicates that the UAS has received and understood the request, but
that the request may not have been authorized or processed by the server
• REDIRECT (3XX): Server has returned possible locations. The client should retry request at another
server. Generally sent by a SIP server acting as a redirect server in response to an INVITE.
o 300 Multiple Choices: Multiple Contact header fields, which indicate that the location service
has returned multiple possible locations. They should be tried in the order in which they were
listed in the response
o 301 Moved Permanently: This redirection response contains a Contact header field with the
new permanent URI of the called party. The address can be saved and used in future INVITE
requests
o 302 Moved Temporarily: This redirection response contains a URI that is currently valid but not
permanent. During call forward situation, we will see 302
o 305 Use Proxy: This redirection response contains a URI that points to a proxy server
o 380 Alternative Service: This response returns a URI that indicates the type of service that the
called party would like. An example might be a redirect to a voicemail server
11
• CLIENT ERROR (4XX): The request has failed due to an error by the client. The client may retry the
request
o 400 Bad Request: This response indicates that the server did not understand the request
o 401 Unauthorized: This response indicates that the request requires the user to perform
authentication & the authentication may fail.
o 402 Payment Required: This response is a placeholder for future definition in the SIP protocol.
It could be used to negotiate call completion charges
o 403 Forbidden: This response is used to deny a request
o 404 Not Found: This response indicates that the user identified by the Request-URI cannot be
located by the server
o 405 Method Not Allowed: This response indicates that the server or user agent has received
and understood a request but is not willing to fulfil the request. An example might be a
REGISTER request sent to a user agent.
o 406 Not Acceptable: This response indicates that the request cannot be processed due to a
requirement in the request message.
o 407 Proxy Authentication Required: This request sent by a proxy indicates that the UAC must
first authenticate itself with the proxy before the request can be processed
o 408 Request Timeout: This response is sent when an Expires header field is present in an
INVITE request, and the specified time period has passed
o 415 Unsupported Media Type: This response sent by a user agent indicates that the media
type contained in the INVITE request is not supported. For example, a request for a video
conference to a PSTN gateway that only handles telephone calls will result in this response
o 480 Temporarily Unavailable: This response indicates that the request has reached the correct
destination, but the called party is not available for some reason. The reason phrase should be
modified for this response to give the caller a better understanding of the situation. The
response should contain a Retry-After header indicating when the request may be fulfilled
o 483 Too Many Hops: This response indicates that the request has been forwarded the
maximum number of times as set by the Max-Forwards header in the request
o 486 Busy Here: This response is used to indicate that the user agent is busy. This response is
equivalent to the busy tone in the PSTN
o 487 Request Terminated: For pending Invites to terminate
12
• SERVER ERROR (5XX): The request has failed due to an error by the server. The request may be
retried at another server
o 501 Not Implemented: This response indicates that the server cannot process the request
because it is not supported. This response can be used to decline a request containing an
unknown method
o 502 Bad Gateway: This response is sent by a proxy that is acting as a gateway to another
network and indicates that some problem in the other network is preventing the request from
being processed
o 503 Service Unavailable: This response indicates that the requested service is temporarily
unavailable. The request can be retried after a few seconds or after the expiration of the Retry-
After header field
o 504 Gateway Timeout: This response indicates that the request failed due to a timeout
encountered in the other network to which the gateway connects
o 505 Version Not Supported: This response indicates that the server has refused the request
because of the SIP version number of the request. There is only one version of SIP (version 2.0)
currently implemented
• GLOBAL FAILURE (6XX): The request has failed. The request should not be tried again at this or
other servers
o 600 Busy Everywhere: If there is a possibility that the Request could be answered in other
locations, this response should not be sent
o 604 Does Not Exist Anywhere: This response is similar to the 404 Not Found response but
indicates that the user in the Request-URI cannot be found anywhere
o 606 Not Acceptable: This response can implement session negotiation capability in SIP. This
response indicates that some aspect of the desired session is not acceptable to the UAS, so the
session cannot be established. The response may contain a Warning header field with a
numerical code describing precisely what was not acceptable
13
SIP/2.0 200 OK
Via: SIP/2.0/TLS [Link]:5061;branch=z9hG4bK8f0ecbd0
From: "Tom Cruise"
<sip:+12148883759@[Link];user=phone>;tag=530037cdf3154211838df2c946301
eb5
>> From won’t change even if the direction of the message is changed. 200 OK is a response
coming from the other side.
To: <sip:+919495860708@[Link];user=phone>;tag=93984964_c3356d0b_4550fce5-9694-
4a77-9dee-7b21b5efd33d
>> TO won’t change even if the direction of the message is changed.
Call-ID: bec174eecf47582ba2613ba0008d04bc
>> Per call-leg Unique identifier
CSeq: 1 INVITE
>> Call Sequence Number: Each SIP Request in same dialogue follows same number, here it is 1
Contact: <sip:[Link];transport=tls>
Record-Route: <sip:[Link];transport=tls;lr>
Supported: sdp-anat
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,NOTIFY
Server: Mediant SW/v.7.20A.258.271
Content-Type: application/sdp
Content-Length: 615
X-Twilio-CallSid: CA9e1d2c4ad36a3289514c55867df090c0
v=0
o=root 234136994 1031931032 IN IP4 [Link]
s=Twilio Media Gateway
c=IN IP4 [Link]
t=0 0
a=ice-lite
m=audio 6060 RTP/SAVP 0 8 101
c=IN IP4 [Link] >> IP Address where the other party sends media
a=rtpmap:0 PCMU/8000 >> G711 mu-law codec with a sampling rate of 8 kHz
a=rtpmap:8 PCMA/8000 >> G711 A-law codec with a sampling rate of 8 kHz
a=rtpmap:101 telephone-event/8000 >> In-band DTMF signaling with a sampling rate of 8 kHz
a=fmtp:101 0-16
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:r/Tlfzi1e9pw7FSyFDu6mftjmI84ckaIDdKWeyh5
a=ptime:20
a=maxptime:150
a=sendrecv
a=ice-ufrag:gnkKXbpwUmX2yyJM
a=ice-pwd:cx98rIkZNMU0qwbOF58Tk447
a=candidate:1222572796 1 udp 2130706431172.191.19.115 6060 typ host
a=candidate:1222572796 2 udp 2130706430 [Link] 6061 typ host
a=mid:1
14
Microsoft Teams Direct Routing with all SBCs (AudioCodes, Ribbon, CUBE,
AnyNode SBCs)
SSIP + SRTP
Teams & Phone System
SSIP + SRTP ITSP / PSTN
Azure AD AudioCodes Ribbon Cisco CUBE AnyNode
SBC SBC SBC SBC
Web
Server
Microsoft 365
Azure Cloud
INTERNET
PROVIDER
INTERNET
PROVIDER
Internet Modem
MS Teams MS Teams MS Teams MS Teams +91-9495860708
IP Phones Users IP Phones Users
• Direct Routing enables organizations to Bring Your Own Carrier (BYOC) / Bring Your Own Trunk
(BYOT) to Teams infrastructure.
• Direct Routing enables to connect Session Border Controllers (SBCs) to the Microsoft Phone System,
allowing them to use their existing PSTN carrier (or telephony infrastructure) with Teams.
• With Direct Routing, organizations can leverage their own preferred telephony providers and
connect them to Microsoft Teams, enabling users to make and receive calls through the Teams
client.
• It essentially allows organizations to integrate their existing phone systems with Teams, enabling
seamless communication across different channels.
• For a user to take advantage of Direct Routing (extending the call from Teams infrastructure to the
external world), the Microsoft Teams Basic and Teams Phone System Add-on licenses are
required. The Phone System licenses are usually bundled with the standard license packs like Office
365 E5, Microsoft 365 E5, etc.
15
Microsoft Teams Direct Routing Specialty Training
with all popular enterprise SBCs (Fast Track business ready training)
Udemy Course Link:
[Link]
Azure Cloud Microsoft Teams Enterprise SBCs
1. Cloud Computing and Azure 7. Microsoft 365 Admin Center 14. Deployment, Configure &
Basics 8. Licensing & Subscriptions Troubleshoot below SBCs,
2. Domain Configuration 9. MS Teams Admin Center 15. AudioCodes SBC
3. Azure vNet 10. Direct Routing 16. Ribbon SBC
4. Azure Subnet 11. Dial Plan, Voice Route 17. Cisco CUBE SBC
5. Network Security Group 12. Voice Routing Policy 18. AnyNode SBC
6. Azure Virtual Machine 13. PSTN Usage Record
16
About the Author
Abdul Jaseem (AJ), a Unified Communications and Collaboration expert with over a decade of
experience in Cisco and Microsoft UC Technologies. Currently employed as a Collaboration
Solution Architect and offering UC project consultation services to numerous clients across the
world. I possess expertise in several UC and VoIP Technologies such as Microsoft Teams
Telephony, Session Border Controllers, Cisco platforms including Cisco Unified Communications
Manager (CUCM), Cisco Unity Connection (CUC), IM and Presence (IMP), Unified Contact Center Express (UCCX), Voice
Gateways, PRI, SIP, Cisco Unified Border Element (CUBE), Expressways and Webex.
My professional journey began as a Desktop Support Technician at a retail supermarket chain in Dammam, Saudi Arabia.
After two years, I returned to India, and worked as a Technical Trainer and later as an Escalation Engineer for various
organizations, specializing in UC and Collaboration Technology, Later I served as a Consulting Engineer at Cisco TAC
Collaboration team in Bangalore, India for 5 years.
With a CCIE Collaboration #59174 certification as my cornerstone, I have continuously expanded my skill set to
encompass various industry-standard certifications. These include VMware VCP, DevNet, AWS Solution Architect
Associate, Certified Kubernetes Administrator, Azure Administrator Associate, and Teams Voice Engineer Expert
certifications.
Throughout my career, I have honed my skills in automation and API development, leveraging cutting-edge tools and
methodologies to streamline processes and enhance efficiency. My proficiency in this area has been recognized through
multiple awards from Cisco and other leading firms for innovation and automation.
As a UC Architect, I thrive on solving complex challenges and architecting solutions that empower organizations to
optimize their communication and collaboration infrastructure. Whether it's designing scalable UC systems,
implementing advanced collaboration platforms, or integrating emerging technologies, I am dedicated to delivering
transformative solutions that drive business success. I am committed to staying up-to-date with the latest trends and
best practices in UC&C and actively contribute to the community through speaking engagements, mentorship
programs, and industry forums.
As a Trainer, I have delivered numerous trainings for clients across the globe (in-person as well as remote). My mission
is to empower organizations to harness the full potential of Unified Communications and Collaboration technologies,
enabling them to connect, communicate, and collaborate more effectively in today's digital age. Thank you for reaching
at this point, I wish good luck for your learnings.
Regards,
Abdul Jaseem, UC Architect
WhatsApp: +91-859-0101-859
LinkedIn: [Link]
YouTube: [Link]
17