s. As a consequence, a SIP message apparently issued from iptel.org could not be sent by a user outside iptel.org. The solution adopted here is described in RFC 4474 [18]. We assume in this technique that there is a trustful third party that is able to issue certificates, which could be in particular acquired by the SIP proxies in the network. To be more concrete, this technique works as follows: Before being able to establish a call, the caller needs to authenticate himself against the SIP proxy of his domain. If the authentication succeeds, the SIP proxy in the caller domain com- putes a hash (using its private key) on some header fields of the SIP message and inserts the result as a new header field (called Identity header) in the same SIP message. The SIP proxy also creates a second header field (called Identity-info) and inserts the URL of the certification authority in it. After that, the SIP message is forwarded further. When the SIP proxy on the callee side receives the SIP message, it uses the URL within the Identity-info field to retrieve the public key used by the SIP proxy of the originating domain. This key is used to verify the signature that the originating SIP proxy has inserted in the forwarded SIP message. 23.4.1.2 Proxy Check Module In spite of its high reliability, the authentication module described earlier requires a trusted third party for issuing certificates which could make this module less attractive. In addition, encryption and decryption can generate a lot of processing that can add delays to communications. For these reasons, we suggest here another module that has the same spirit, but which is less complex and does not require third party nor encryption. Unfortunately, this module is less reliable than the one mentioned previously. One mode of operation in SIP networks is to use the proxy of the domain not only for incoming calls, but also for all outgoing calls. If users want to make an outgoing call, they don't send their INVITE directly to the proxy of the target domain. Instead,