Subject: [Sip] Changed From Tag in Spiral Request

From: Manjunath Warad <[email-masked]>
Date: Tue, 01 Sep 2009 14:13:49 +0530

Hi All,
	If a UA receives a request in a spiralled way then shouldn't the
>From Tag and Call-ID same as the originated request?
	Should the UA accept the received request as spiral if call-ID is
same and From tag is different? Please let me know if there is any business
use case of such scenario if you have come across.
	Since the match algo is not well defined for spiral in RFC, we need
a reference.

Thanks,
Manju

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 30 Sep 2009 17:27:45 -0400

> Since the match algo is not well defined for spiral in RFC, we need

Strictly speaking a UA cannot receive a spiraled request, since the
request cannot have passed through the UA before.  A UA can receive a
"merge" request, that is, a request which is another fork of a request
that it has received before.  Merged requests are detected per section
8.2.2.2 of RFC 3261:  the Call-Id, the from-tag, and the CSeq are the
same.  As you notice, if the Call-Id's are the same, the from-tag's must
be the same, but if some intermediate element has modified the from-tag,
it is clear that the UA should consider the requests to not be merged
requests.

In regard to a proxy, which can receive a spiraled request, that is, a
request one of whose ancestral requests passed through the proxy:  The
proxy does not need to be aware that the request is spiraled, since it
only needs to recognize "hop-by-hop transactions", which are identified
by the branch parameter value of the topmost Via header.

Dale