Hi All,
Here is the issue I meet in our product:
1. Client A send the option request to Server with the branch parameter = XXX, sent-by=A
2. Server send the 200 response to the Client A immediatly
3. within 64*T1,Client B send the option request to Server with the same branch parameter =XXX , but sent-by=B.
4. The Server send the last 200 response to Client A, instead of Client B. So Client B can't receive any response for this option request.
It seems that the resiprocate handle the second option request from Client B with the old transaction and consider this request as retransmission.
Here are my question:
1. In sip standard, the sent-by in via header is also the key value to distinguish transaction. so whether the resiprocate need enhancement for that?
2. The call-ids are different between these two option request, so the designer of clients explain that as below. is he right for the dialog and transaction explanation? in his opinion, the second option request shouldn't handled by the old transaction,because the call-id is different from the first one.
First and foremost, the Server should be using Call-ID to distinguish between SIP dialogues. Before it ever get to looking at Via header Branch-IDs, they should 1st be looking at Call-ID to establish unique SIP dialogue contexts. From the RFC: Call-ID contains a globally unique identifier for this call,
generated by the combination of a random string and the softphone's
host name or IP address. The combination of the To tag, From tag,
and Call-ID completely defines a peer-to-peer SIP relationship
between Alice and Bob and is referred to as a dialog.
You are appreciated if can provide help.
Thanks very much.