Hi, Last time when i sent the same query diagram got currupted this time i believe it should not happen. I have a doubt about Merged Requests. Please go through the following section of RFC3261.
=========================================================================== 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. ============================================================================ Now consider the following scenario: Note: I am using a, b, c for branch ids just make it more readable. ________ | | | Client| |_______| | | Via: <client>; branch=a | V ________ |forking| |proxy | |_______| |________________________________________________ | forking proxy forks it in two | | | | | | | | | | | | Via: <client>; branch=a | Via: <client>; branch=a | Via: <forking_proxy>; branch= b | Via: <forking_proxy>; branch= c V V ________ ________ | | | | |proxy_A| |proxy_B| |_______| |_______| | | | Via: <client>; branch= a |Via: <client>; branch=a | Via: <forking_proxy>; branch= b |Via: <forking_proxy>; branch = c | Via: <proxy_A>; branch= d |Via: <proxy_B>; branch = e V | ________ | | | | |Server |<------------------------------------------- |_______| Implementations complaint to RFC3261 (section 17.2.3) for matching transaction wont be able to distinguish between these requests and this request which follows the path of proxy B will hit exactly at the same transaction as request through A because top via headers are identical. (branch, sent-by-value and method all three will be same for both the requests) Transaction layer in this case will return the same response as it returned for the previous request coming from A. Transaction layer treats the second request as a retransmission whereas it is not a retransmission and a 482 response is expected to be returned for this request. One way to resolve the above mentioned issue is to compare the complete via list. Now if we compare the complete list then request coming from B will not match with any of the transactions and will reach UA. Now UA core complaint to RFC3261 (section 8.2.2.2) will know that this request did not match any of the transactions and it will attempt to search a transaction having the same CallId, From Tag and CSeq as this current request has. It will be able to do so as transaction for request A still exists, and hence it will be able to return 482 response. Now my doubt is that RFC3261 does not talk about comparing the complete via list then how could it write section 8.2.2.2 because this code leg is not going to hit in any scenario. (means never be executed). Because all merging requests will always be returned with previous provisional response by transaction layer only, UA core wont even know of their arrival. Please answer this doubt, it is eating up my head. Thanks in advance Regards - Nitin Arora _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
