[prev in list] [next in list] [prev in thread] [next in thread]
List: sip-implementors
Subject: Re: [Sip-implementors] How to recognize Merging Requests at transactionLayer ( 482 Response )
From: "Anshuman Rawat" <anshuman.rawat () conexant ! com>
Date: 2006-05-29 6:43:17
Message-ID: 012BC014351183459BEA509C6496F95A327D2F () hyd-mail2 ! bbnet ! ad
[Download RAW message or body]
Nitin,
Your question was answered by Dale when you posted it the first time.
Quoting him -
"The above chart is incorrect -- when a proxy sends a request on, it
adds it's Via *first*. Thus, the two sets of Via's shown are reversed
from what they should be. And the two copies of the request have
different topmost branch parameters, "b" and "c".
(interop.pingtel.com has a test for merged requests. We've discovered
that almost all UAs do not handle merged requests correctly the first
time they are tested.)"
e.g. when the request through Proxy A reaches the server the VIA header
would be in the order -
Via: <proxy_A>; branch=d
Via: <forking_proxy>; branch=b
Via: <client>; branch= a
That solves the issue.
Anshuman
-----Original Message-----
From: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of nitin
arora
Sent: Monday, May 29, 2006 9:56 AM
To: sip-implementors@cs.columbia.edu
Subject: [Sip-implementors] How to recognize Merging Requests at
transactionLayer ( 482 Response )
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
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
********************** 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."
**********************************************************************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic