Hi Ajay,
I think the main point that we are missing is that if we match requests as mentioned in section 17.2.3, we have to take the branch in via into consideration. Now that answers all questions.
In the example that you have mentioned, the via stack is growing top to bottom, which I guess is not the case, it grows from bottom to top and comparing the first bia branch should be good enough indication.
regards
Rayees
[EMAIL PROTECTED] wrote: -----I think the main point that we are missing is that if we match requests as mentioned in section 17.2.3, we have to take the branch in via into consideration. Now that answers all questions.
In the example that you have mentioned, the via stack is growing top to bottom, which I guess is not the case, it grows from bottom to top and comparing the first bia branch should be good enough indication.
regards
Rayees
To: <[email protected]>
From: "Nitin Arora" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
Date: 05/26/2006 02:19PM
Subject: [Sip-implementors] How to recognize merging requests at transactionlayer ( 482 Response )
Hi,
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:
________
| |
|Client |
|_______|
|
| Via:; branch=z9hG4bk238210jeq via list then how could it write section 8.2.2.2 because this code leg
|
V
________
|forking|
|proxy |
|_______|
|_______________________________________________________
| forking proxy forks it in two |
| |
| |
| |
| |
| |
| Via:; branch=z9hG4bk238210jeq | Via: ; branch=z9hG4bk238210jeq
| Via:; branch=z9hG4bk28943ksh | Via: ; branch=z9hG4bk25649kfg
V V
________ ________
| | | |
|proxy_A| |proxy_B|
|_______| |_______|
|
| Via:; branch=z9hG4bk238210jeq |Via: ; branch=z9hG4bk238210jeq
| Via:; branch=z9hG4bk28943ksh |Via: ; branch=z9hG4bk25649kfg
| Via:; branch=z9hG4bk21212eer |Via: ; branch=z9hG4bk20303opp
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 are 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 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
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
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
*****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. FSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
_______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
