Key Insights
DNS configuration determines routing reliability and failover capabilities. Proper NAPTR and SRV records enable automatic server discovery, load distribution across multiple endpoints, and seamless failover when primary servers become unavailable. Organizations that skip this step and rely on IP-based addressing lose the flexibility to scale infrastructure, perform maintenance without downtime, or adapt to changing network conditions. The investment in correct DNS setup pays dividends throughout the system's lifecycle.
Security requires hop-by-hop TLS enforcement, not just endpoint encryption. The sips: scheme mandates encrypted transport on every connection between user agents and proxies, ensuring that signaling data remains protected throughout its journey. However, this differs fundamentally from end-to-end encryption—intermediate proxies can still inspect and modify call setup information. For complete protection, combine secure signaling with SRTP for media encryption and implement authenticated identity mechanisms like RFC 4474.
Modern AI voice agents integrate seamlessly using standard addressing protocols. Rather than requiring specialized infrastructure, contemporary AI platforms register as standard endpoints with their own addresses, accepting calls through existing trunks and routing logic. This architectural approach means organizations can deploy intelligent automation—handling after-hours inquiries, screening calls, or managing appointments—without replacing phone systems or learning new protocols. The same DNS records, security policies, and monitoring tools apply to both human and AI endpoints.
NAT traversal remains the primary deployment challenge for distributed systems. Private IP addresses in Contact headers, symmetric NAT configurations, and premature connection timeouts cause one-way audio, registration failures, and intermittent connectivity issues. Solutions include implementing RFC 5626 for persistent outbound connections, deploying STUN/TURN servers for address discovery, configuring aggressive keep-alive mechanisms, and considering Session Border Controllers for complex network topologies. Organizations that address NAT traversal proactively avoid the majority of support calls and user frustration.
When you place a VoIP call, the system needs to know exactly where to route that call—just like how email needs an address to reach the right inbox. That's where SIP URIs come in. A SIP URI (Session Initiation Protocol Uniform Resource Identifier) is the addressing format that identifies users and resources in SIP-based communications systems. It looks similar to an email address, following the format sip:user@domain, and contains all the information needed to initiate and maintain a communication session between parties.
Understanding this addressing scheme is essential for anyone implementing or managing modern voice infrastructure. Whether you're configuring enterprise phone systems, building AI-powered voice agents, or troubleshooting call routing issues, this guide provides the technical depth and practical insights you need.
What Is a SIP URI?
A SIP URI is a standardized addressing format defined in RFC 3261 that identifies communications resources in Session Initiation Protocol networks. Think of it as a phone number for the internet age—but instead of just digits, it uses a flexible format that can include usernames, domains, IP addresses, and various parameters that control how calls are routed and secured.
The basic syntax follows this pattern:
sip:user@host:port;parameters?headers
Unlike traditional phone numbers tied to specific physical locations or devices, these identifiers can route to multiple endpoints, traverse different networks, and adapt based on user preferences and availability. They enable the kind of flexible, internet-based calling that powers everything from softphones and desk phones to contact centers and AI voice agents.
The addressing scheme comes in two variants: sip: for standard connections and sips: for secure connections requiring Transport Layer Security (TLS) on each hop. This distinction becomes critical when security and privacy requirements dictate that voice traffic must be encrypted throughout its entire path.
How the Addressing Format Works
The structure mirrors email addresses for good reason—both solve similar problems of routing messages across distributed networks. The user portion identifies a specific person or resource, while the host portion indicates the domain or server responsible for that resource. When someone initiates a call, the system performs DNS lookups to locate the appropriate servers, establishes connections, and routes the session to the intended destination.
For example, sip:alice@example.com tells the system to contact user "alice" at the domain "example.com". The system then uses DNS records (NAPTR and SRV) to discover which servers handle SIP traffic for that domain, establishes a connection, and delivers the call invitation.
Understanding SIP URI Components
Each part of the addressing format serves a specific purpose in routing and controlling communication sessions. Let's break down the complete syntax:
Scheme (sip: or sips:)
The scheme identifier appears at the beginning and determines the security requirements:
- sip: - Standard scheme that allows connections over UDP, TCP, or TLS based on configuration and availability
- sips: - Secure scheme that mandates TLS encryption on every hop from sender to recipient
When you use the secure variant, you're instructing every proxy and server in the path to use encrypted transport. If any hop cannot establish a secure connection, the request should fail rather than falling back to unencrypted transport. The default port for standard connections is 5060, while secure connections use 5061.
User Portion (Userinfo)
The user portion identifies the specific resource being addressed. This can be:
- A username:
sip:bob.smith@company.com - A telephone number:
sip:+12125551234@gateway.com - An extension:
sip:1001@pbx.internal - A service identifier:
sip:support@helpdesk.com
For telephone numbers, the format typically includes the user=phone parameter to indicate that the user portion should be treated as a tel URI. This helps systems properly handle E.164-formatted numbers.
Host Component
The host identifies where the resource can be reached. This can be:
- Domain name:
sip:alice@voip-provider.com(requires DNS resolution) - IP address:
sip:bob@192.168.1.100(direct connection) - FQDN:
sip:carol@pbx.office.company.com(fully qualified domain)
Using domain names is recommended because it provides flexibility—the underlying IP addresses can change without breaking the addressing. When a domain is used, the system performs DNS lookups (NAPTR and SRV records) to discover the actual servers handling traffic for that domain.
Port Specification
While optional, you can specify a non-standard port:
sip:user@example.com:5080
When a port is explicitly provided, DNS SRV lookups are bypassed, and the system connects directly to the specified host and port. If no port is given, the system uses DNS service records to determine the correct port, or falls back to the defaults (5060 for standard, 5061 for secure).
URI Parameters
Parameters modify how the request should be handled. They appear after the host, separated by semicolons:
- transport: Specifies protocol (tcp, udp, tls, sctp) -
sip:bob@example.com;transport=tcp - user: Indicates format of user portion (phone, ip) -
sip:+15551234@gw.com;user=phone - method: Suggests which SIP method to use
- lr: Indicates loose routing support
- maddr: Multicast address for the request
- ttl: Time-to-live for UDP multicast
Note that the transport=tls parameter has been deprecated. When secure transport is required, use the sips: scheme instead.
Header Fields
Headers can be embedded in the URI using the ? separator:
sip:support@company.com?subject=urgent&priority=high
These headers get converted into actual SIP message headers when the request is constructed. This feature is particularly useful when encoding call parameters in clickable links on web pages or in applications.
Practical Examples and Use Cases
Seeing the format in action helps clarify how different components work together in real-world scenarios.
Basic User-to-User Calling
The simplest form addresses a user at a domain:
sip:alice@example.com
When this address is used, the system performs DNS lookups for example.com, discovers the SIP servers, and routes the call invitation. This is the most common format for user-facing addresses.
Telephone Number Integration
When integrating with traditional phone networks, telephone numbers are formatted with the user=phone parameter:
sip:+12125551234@gateway.example.com;user=phone
This tells the system that the user portion contains an E.164 telephone number. The gateway then bridges the call to the public switched telephone network (PSTN).
Direct IP Dialing
For point-to-point connections without DNS, you can dial directly to an IP address:
sip:192.168.1.51:5060
This bypasses all DNS lookups and proxy routing, establishing a direct connection to the specified IP and port. This approach is useful for testing or in closed networks, but loses the flexibility and features that proxies provide.
Secure Connections
When security is required on all hops, use the secure scheme:
sips:bob@secure-domain.com
Every server and proxy in the path must establish TLS connections. If any hop cannot provide secure transport, the call fails rather than falling back to unencrypted communication.
Transport-Specific Routing
You can specify the transport protocol explicitly:
sip:carol@example.com;transport=tcp
This instructs the system to use TCP rather than UDP for this connection. This can be important when traversing firewalls or when message size exceeds UDP packet limits.
SIPS: Secure SIP Addressing
The secure variant addresses a critical need in voice communications: ensuring that signaling traffic remains encrypted throughout its entire path. While standard addressing allows but doesn't require encryption, the secure scheme mandates it.
How Security Works
When you use a sips: address, you're requiring that:
- Every connection between user agents and proxies uses TLS
- Every connection between proxies uses TLS
- The final connection to the destination user agent uses TLS
- Certificates are validated at each step
This provides hop-by-hop security. Each connection is encrypted, but intermediate proxies can still inspect and modify the signaling (they need to in order to route calls). This differs from end-to-end encryption where only the endpoints can decrypt the content.
When to Use Secure Addressing
The secure scheme is appropriate when:
- Regulatory requirements mandate encrypted signaling (healthcare, finance)
- Corporate security policies require all voice traffic be secured
- Sensitive information is discussed that requires privacy protection
- You want to prevent eavesdropping on call setup and metadata
However, understand that using secure addressing requires that all devices and servers in the path support TLS and have valid certificates. If any hop cannot establish a secure connection, the call will fail.
Important Security Considerations
While the secure scheme provides valuable protection, it has limitations:
- Transitive trust: You're trusting every proxy in the path to properly maintain security
- No end-to-end guarantee: Proxies can still see and modify signaling
- Metadata exposure: Even with TLS, proxies see who is calling whom and when
- Media encryption separate: The secure scheme only addresses signaling; media encryption requires SRTP
For truly end-to-end security, combine secure signaling with SRTP for media encryption and consider using SIP Identity (RFC 4474) for authenticated identity.
RFC 5630 Updates
The original RFC 3261 specification included a "last-hop exception" that allowed the final connection to use unencrypted transport even with a sips: address. RFC 5630 deprecated this exception, requiring TLS on all hops including the last one. This change closed a significant security gap where the most vulnerable connection—often to a user agent behind a firewall—could be unencrypted.
How Call Routing Works
Understanding how the system routes calls using these addresses helps you troubleshoot issues and design effective voice architectures.
DNS Resolution Process
When a user agent needs to send a request to sip:bob@example.com, it follows this resolution process:
- NAPTR lookup: Query DNS for NAPTR records at example.com to determine available transport protocols
- SRV lookup: Based on NAPTR results, query SRV records for _sip._tcp.example.com or _sip._udp.example.com
- A/AAAA lookup: If no SRV records exist, fall back to A or AAAA records for the domain
- Default port: If no port information is found, use 5060 for standard or 5061 for secure
This layered approach provides flexibility and redundancy. Domains can advertise multiple servers, specify preferred protocols, and provide fallback options.
Proxy Routing Behavior
Proxies play a central role in routing requests to their destinations. When a proxy receives a request:
- Check Request-URI: Determine if the proxy is responsible for the domain
- Consult location service: If responsible, look up registered contacts for the user
- Apply routing logic: Consider user preferences, time-based routing, availability
- Fork if needed: Send the request to multiple destinations simultaneously or sequentially
- Insert Record-Route: Add itself to the path so mid-dialog requests route correctly
At Vida, our SIP infrastructure handles this routing intelligently while adding AI-powered decision-making. When a call comes in, our system doesn't just route based on static rules—it can analyze caller intent, check business hours, evaluate agent availability, and route to the most appropriate endpoint or AI agent. This transforms simple address-based routing into intelligent call orchestration.
Registration and Contact Bindings
For dynamic routing to work, user agents must register their current location. When Bob's phone registers with sips:bob@bobphone.example.com, it's telling the registrar "I'm reachable at this address." The registrar stores this binding in its location service.
Later, when Alice calls sip:bob@example.com, the proxy consults the location service, finds the registered contact, and forwards the request to sips:bob@bobphone.example.com. This indirection is what enables mobility—Bob can move between devices and networks, and calls still reach him as long as his current device is registered.
SIP vs SIPS Routing Rules
The routing behavior differs based on whether standard or secure addressing is used:
For sip: addresses:
- Proxies can forward to either sip: or sips: contacts
- Transport security is best-effort unless explicitly required
- The system prefers secure transport when available but doesn't mandate it
For sips: addresses:
- Proxies must only forward to sips: contacts
- Every hop must use TLS transport
- If secure transport isn't available, the request fails with 480 Temporarily Unavailable
- "Downgrading" from sips: to sip: is forbidden
This ensures that when someone uses secure addressing, they get either full security or a clear failure—never a false sense of security from partial protection.
Implementation Best Practices
Successfully deploying and managing SIP-based systems requires following proven practices that avoid common pitfalls.
Use Domain Names, Not IP Addresses
Always prefer domain-based addresses over IP-based ones:
- Flexibility: IP addresses can change without breaking the addressing
- Load balancing: DNS can distribute traffic across multiple servers
- Failover: SRV records provide automatic fallback to backup servers
- Maintenance: Servers can be upgraded or replaced without changing addresses
Reserve IP-based addressing for testing, debugging, or specific point-to-point scenarios.
Implement Proper DNS Records
Configure your DNS infrastructure correctly:
- Add NAPTR records to advertise available protocols
- Create SRV records for _sip._tcp and _sip._udp
- For secure connections, add SRV records for _sips._tcp
- Maintain accurate A/AAAA records as fallbacks
- Set appropriate TTL values to balance caching and flexibility
Proper DNS configuration ensures that clients can discover your servers reliably and efficiently.
Handle Both SIP and SIPS
Design your infrastructure to support both standard and secure addressing:
- Configure proxies to accept connections on both port 5060 and 5061
- Obtain and maintain valid TLS certificates
- Implement policies for when to require secure transport
- Provide clear error messages when security requirements aren't met
Even if your current deployment doesn't require secure addressing, building in support makes future security upgrades much easier.
Validate URI Format
Always validate addresses before using them:
- Check that the scheme is either sip: or sips:
- Verify the host portion is a valid domain or IP address
- Ensure parameters follow correct syntax
- Reject malformed URIs with clear error messages
Proper validation prevents security issues and provides better user experiences when addresses are mistyped.
Use Parameters Appropriately
Leverage URI parameters to control behavior, but use them judiciously:
- Specify transport only when necessary (firewall requirements, message size)
- Use user=phone for telephone numbers to ensure proper handling
- Avoid deprecated parameters like transport=tls
- Document any custom parameters your system uses
Implement Security Controls
Protect your infrastructure from common threats:
- Authentication: Require digest authentication or certificate-based auth
- Rate limiting: Prevent registration and call flooding attacks
- IP filtering: Restrict which networks can reach your servers
- Fail2ban: Automatically block sources of repeated failed attempts
- Encryption: Use TLS for signaling and SRTP for media
These controls prevent toll fraud, denial of service attacks, and unauthorized usage.
Common Issues and Troubleshooting
Even well-designed systems encounter problems. Here's how to diagnose and resolve common issues.
Registration Failures
Symptom: User agent cannot register with the server
Common causes:
- Incorrect credentials (username/password mismatch)
- Network connectivity issues (firewall blocking ports)
- DNS resolution failures
- Certificate validation errors (for secure connections)
- Expired or invalid authentication tokens
Troubleshooting steps:
- Verify credentials match server configuration
- Test network connectivity (ping, traceroute)
- Check DNS resolution (nslookup, dig)
- Examine server logs for specific error messages
- For TLS issues, verify certificate validity and trust chain
Call Routing Problems
Symptom: Calls don't reach intended destination or fail with 404 Not Found
Common causes:
- User not registered (no contact binding exists)
- Incorrect Request-URI format
- DNS resolution pointing to wrong server
- Proxy routing logic errors
- Scheme mismatch (sips: address but sip: registration)
Troubleshooting steps:
- Verify user is registered (check location service)
- Validate the Request-URI format
- Trace DNS resolution path
- Review proxy routing configuration
- Check for scheme consistency between registration and call
TLS Connection Failures
Symptom: Secure connections fail to establish
Common causes:
- Certificate expired or not yet valid
- Hostname mismatch between certificate and address
- Untrusted certificate authority
- TLS version incompatibility
- Cipher suite mismatch
Troubleshooting steps:
- Check certificate validity dates
- Verify certificate hostname matches the domain
- Ensure CA certificate is in trust store
- Review supported TLS versions on both sides
- Check cipher suite compatibility
NAT Traversal Issues
Symptom: Calls work in one direction but not the other, or media flows but signaling doesn't
Common causes:
- Private IP addresses in Contact headers
- NAT timeout closing connections prematurely
- Symmetric NAT preventing incoming connections
- Firewall blocking return traffic
Troubleshooting steps:
- Implement RFC 5626 (outbound connections) to maintain persistent connections
- Use STUN/TURN servers for NAT traversal
- Configure keep-alive mechanisms to prevent timeout
- Consider using a Session Border Controller (SBC)
- Review firewall rules for both signaling and media ports
Integration with Modern Voice Systems
Understanding how the addressing format integrates with contemporary voice architectures helps you build more capable systems.
Enterprise VoIP Deployments
In enterprise environments, the addressing scheme provides the foundation for unified communications:
- Extension dialing: Internal users dial short extensions that map to full addresses
- Directory integration: Corporate directories provide addresses for click-to-call functionality
- Presence integration: Addresses link to presence information showing user availability
- Conferencing: Conference rooms have their own addresses for easy joining
- Voicemail: Voicemail systems use addresses for message deposit and retrieval
SIP Trunking
SIP trunks connect enterprise phone systems to service providers using these addresses:
- Trunk addressing: Provider assigns addresses for inbound and outbound traffic
- DID mapping: Direct Inward Dial numbers map to internal addresses
- Caller ID: Outbound calls present addresses that identify the organization
- Failover: Multiple trunk addresses provide redundancy
AI Voice Agents
At Vida, we use the standard addressing format as the foundation for AI-powered voice agents. Our platform assigns addresses to AI agents just like human users, enabling seamless integration with existing phone systems:
- Agent registration: AI agents register their addresses just like softphones
- Intelligent routing: Calls route to AI agents based on intent, language, or business logic
- Human handoff: When needed, AI agents transfer calls using standard SIP REFER
- Multi-channel: The same addressing scheme works across phone, web, and mobile channels
This approach means you don't need special infrastructure for AI agents—they work with your existing SIP trunks, PBX systems, and contact center platforms. The AI agents at Vida can handle inbound calls, make outbound calls, and integrate with your business workflows, all using standard SIP addressing and protocols. Vida integrates seamlessly with existing telecom networks and business phone systems over SIP.
WebRTC Integration
Modern web-based communications use the same addressing format:
- Browser-based calling: Web applications use addresses for click-to-call functionality
- Gateway translation: WebRTC signaling converts to standard SIP for interoperability
- Unified addressing: Users have one address regardless of device or client
Security Considerations
Voice systems face unique security challenges that require careful attention.
Common Threats
Understanding the threat landscape helps you implement appropriate defenses:
- Toll fraud: Attackers gain access to make expensive international calls
- Registration hijacking: Unauthorized parties register addresses to intercept calls
- Denial of service: Flooding systems with requests to disrupt service
- Eavesdropping: Intercepting signaling or media to spy on conversations
- Caller ID spoofing: Falsifying calling party information
- VoIP spam: Unsolicited calls from automated systems
Defense Strategies
Implement multiple layers of protection:
- Strong authentication: Require digest authentication with complex passwords or certificate-based authentication
- Encryption: Use TLS for signaling and SRTP for media
- Network segmentation: Isolate voice traffic from general internet traffic
- Rate limiting: Restrict registration attempts and call rates per source
- Geographic restrictions: Block traffic from countries you don't do business with
- Monitoring: Watch for unusual patterns (sudden spike in international calls, registration attempts from multiple IPs)
- Intrusion prevention: Deploy fail2ban or similar tools to automatically block attackers
STIR/SHAKEN for Caller Authentication
The STIR/SHAKEN framework provides cryptographic authentication of caller identity:
- Service providers sign calls with certificates
- Signatures travel with the call through the network
- Receiving parties can verify the calling number hasn't been spoofed
- Helps combat robocalls and caller ID spoofing
While STIR/SHAKEN operates at a higher level than basic addressing, it relies on the same infrastructure and addresses the growing problem of fraudulent caller identification.
Future Developments
Voice communications technology continues to evolve, bringing new capabilities and approaches.
5G and Network Slicing
Fifth-generation mobile networks use IP Multimedia Subsystem (IMS) architecture built on SIP:
- Voice over New Radio (VoNR) uses SIP for call setup
- Network slicing provides dedicated resources for voice traffic
- Lower latency improves real-time communication quality
- Seamless handoff between Wi-Fi and cellular networks
AI and Machine Learning Integration
Artificial intelligence is transforming how voice systems operate:
- Intelligent routing: ML models predict best destination based on context
- Fraud detection: AI identifies suspicious patterns in real-time
- Quality optimization: Systems automatically adjust codecs and routes for best quality
- Natural language processing: Voice agents understand intent and respond naturally
At Vida, we're pioneering the integration of AI voice agents with standard SIP infrastructure. Our AI Agent Operating System uses the same addressing and routing mechanisms you already know, but adds AI capabilities that can understand caller intent, execute business logic, and provide natural conversational experiences. This means you can deploy AI agents that work seamlessly with your existing phone systems, SIP trunks, and contact center infrastructure.
Enhanced WebRTC Capabilities
Web-based real-time communications continue to mature:
- Better codec support for higher quality audio
- Improved NAT traversal techniques
- Standardized signaling protocols
- Tighter integration with native SIP infrastructure
Getting Started with Implementation
Ready to implement or improve your SIP-based voice infrastructure? Here's a practical roadmap.
For Small Deployments
If you're setting up a small office or team:
- Choose a provider: Select a SIP trunking provider that offers the features you need
- Configure DNS: Set up proper DNS records for your domain
- Deploy user agents: Install softphones or configure desk phones
- Test connectivity: Make test calls to verify routing works correctly
- Implement security: Enable authentication and encryption
- Monitor usage: Watch for issues and unusual patterns
For Enterprise Deployments
Larger organizations need more planning:
- Design architecture: Plan proxy topology, redundancy, and capacity
- Address planning: Create addressing scheme for users, departments, services
- Infrastructure setup: Deploy proxies, registrars, and media servers
- Integration: Connect to existing systems (Active Directory, CRM, etc.)
- Security hardening: Implement comprehensive security controls
- Testing: Conduct thorough testing including failover scenarios
- Training: Educate users and administrators
- Monitoring: Deploy monitoring and alerting systems
Adding AI Voice Capabilities
If you want to enhance your voice infrastructure with AI agents:
- Assess use cases: Identify where AI agents can provide value (after-hours support, call screening, appointment scheduling)
- Choose platform: Select an AI voice platform that integrates with your existing infrastructure
- Configure integration: Configure SIP for seamless inbound and outbound calls with your AI platform
- Design conversations: Create conversation flows and business logic
- Test thoroughly: Validate that AI agents handle expected scenarios correctly
- Deploy gradually: Start with limited deployment and expand based on results
- Monitor and improve: Analyze conversations and refine agent behavior
Vida makes this process straightforward by providing native SIP support that works with your existing infrastructure. Our AI agents register using standard addressing, accept calls through your existing trunks, and can hand off to human agents when needed. You don't need to replace your phone system—you enhance it with AI capabilities that use the same protocols and addressing you already understand.
Resources and Standards
For deeper technical understanding, consult these authoritative resources:
Core RFCs
- RFC 3261: SIP: Session Initiation Protocol (the foundational specification)
- RFC 5630: The Use of the SIPS URI Scheme (clarifications and updates)
- RFC 3263: Locating SIP Servers (DNS procedures)
- RFC 5626: Managing Client-Initiated Connections (outbound connections)
- RFC 4474: Enhancements for Authenticated Identity Management
Related Standards
- RFC 3608: Service Route Discovery (service route header field)
- RFC 5627: Obtaining and Using Globally Routable User Agent URIs (GRUU)
- RFC 3515: The SIP Refer Method
- RFC 4566: SDP: Session Description Protocol
Tools and Software
These open-source tools help with implementation and testing:
- Asterisk: Full-featured PBX platform
- FreeSWITCH: Scalable telephony platform
- Kamailio: High-performance SIP proxy
- SIPp: Testing tool for load and functionality testing
- Wireshark: Network protocol analyzer with SIP support
Conclusion
The SIP URI addressing format provides the foundation for modern voice communications. Understanding its structure, security implications, and routing behavior enables you to build reliable, scalable, and secure voice systems. Whether you're implementing a simple office phone system, deploying enterprise unified communications, or building AI-powered voice agents, these same principles and protocols apply.
The key takeaways:
- The addressing format mirrors email addresses but includes powerful parameters for controlling call behavior
- The secure variant (sips:) mandates TLS on every hop, providing strong security guarantees
- Proper DNS configuration enables flexible routing and failover
- Security requires multiple layers of defense against various threats
- Modern AI capabilities can be added while maintaining compatibility with existing infrastructure
At Vida, we've built our AI voice agent platform on this solid foundation. Our native SIP support means you can deploy intelligent voice agents that work seamlessly with your existing phone systems, trunks, and contact center infrastructure. Whether you need inbound call handling or outbound calling capabilities, our platform uses standard addressing and protocols to integrate naturally into your voice architecture.
Ready to enhance your voice infrastructure with AI capabilities? Explore how Vida can help you build more intelligent, responsive voice experiences while leveraging the SIP infrastructure you already have in place.
