Các bước trong hình trên được diễn giải như sau:
1. Cả hai SIP UA thiết lập kết nối TLS với các proxy đi ra của chúng và nhận thực chúng với kỹ thuật nhận thực Digest. Nếu như proxy đi ra có cùng hostname với registrar, thì SIP UA dùng lại kết nối TLS được dùng trong đăng kắ và các ủy nhiệm được dùng trong quá trình nhận thực Digest.
2. SIP UA trong miền A gửi yêu cầu INVITE tới proxy đi ra của nó qua liên kết đã được đảm bảo. Yêu cầu INVITE chứa ủy nhiệm thắch hợp.
3a. Proxy đi ra trong miền A kiểm tra bản tin INVITE và xác định rằng bản tin sẽ được chuyển tới proxy đi ra trong miền B. Giữa các proxy không có kết nối TLS. Do đó, các proxy đi ra thiết lập kết nối TLS và chúng thay đổi các khóa xác nhận chung của chúng cho nhận thực song hướng, hai proxy này gửi bản tin Certificate trong quá trình bắt tay.
3b. SIP proxy trong miền B có thể có các chắnh sách khác nhau điều khiển các yêu cầu tới. Thắ dụ SIP proxy này chỉ chấp nhận các yêu cầu với cùng tên miền trong header From khi đã được chỉ rõ trong khóa xác nhận chung đã nhận từ proxy đi ra trong miền A.
4. Nếu như các khóa xác nhận chung là hợp lệ, thì proxy đi ra trong miền A chuyển yêu cầu INVITE qua liên kết được bảo vệ.
5. Proxy đi ra trong miền B đã sẵn sàng mở một kết nối TLS với SIP UA trong miền B. Do đó, nó chuyển yêu cầu INVITE tới SIP UA qua liên kết được bảo vệ.
6. Cả hai proxy này đều thêm header Record-Route vào trong bản tin INVITE. Do đó, đáp ứng từ SIP UA trong miền B sẽ đi qua các proxy.
iii. Lời mời Peer-to-Peer
Hình sau minh họa kịch bản một SIP UA không sử dụng proxy hướng đi ra, mời SIP UA trong miền B. SIP proxy trong miền B hoạt động giống như redirect server đối với các yêu cầu đi vào từ SIP UA không được nhận thực, tức là hai SIP UA sẽ được kết nối theo kiểu peer-to-peer (ngang hàng).