Hi I have two questions. 1. Receiver@1.1.1.1 and Receiver@2.2.2.2 register with ser. Client sends an INVITE to ser for Receiver. ser forks these INVITES in parallel to both Receiver@1.1.1.1 and Receiver@2.2.2.2. As both Receivers are online, they both reply with 200 OK. SER then relays BOTH 200 OK's back to the Client. My question: Shouldn't SER send CANCEL to one of the receivers, and relay only ONE 200 OK back to the client? How would I do this? It is not the client's responsibility to send a CANCEL to the SER to relay to one of the receivers, is this correct? This is because the client only sent one invite, therefore it should only receive one OK. ie should SER 'shield' the client from the knowledge of the existence of multiple contact addresses?
2. When I have tls_verify_client = 1 tls_require_client_certificate = 1
in my cfg file, ser still accepts tcp and udp connections, despite tls_require_client_certificate=1. I did a search, and found this way:
if (proto != TLS) { sl_send_reply("403", "Forbidden"); exit; };
However SER is really still listening on UDP and TCP port 5060. Is there a way to configure SER such that it only listens and acknowledges TLS connections?
Thanks Andrew
Andrew T Gin wrote:
Hi I have two questions.
- Receiver@1.1.1.1 and Receiver@2.2.2.2 register with ser.
Client sends an INVITE to ser for Receiver. ser forks these INVITES in parallel to both Receiver@1.1.1.1 and Receiver@2.2.2.2. As both Receivers are online, they both reply with 200 OK. SER then relays BOTH 200 OK's back to the Client. My question: Shouldn't SER send CANCEL to one of the receivers, and relay only ONE 200 OK back to the client? How would I do this? It is not the client's responsibility to send a CANCEL to the SER to relay to one of the receivers, is this correct? This is because the client only sent one invite, therefore it should only receive one OK. ie should SER 'shield' the client from the knowledge of the existence of multiple contact addresses?
No, the 2xx responses must be forwarded to the client as the INVITE transaction cannot be canceled once a final response has been generated by the UAS. Moreover, the proxy would not know _which_ call leg to cancel (which peer is the one the caller wants to talk to?)
Thus, it _is_ the client's responsibility to send a BYE for the call it wants to finish (note that it cannot be canceled at that state).
Regards, Olaf