Subject: Re: [Sip] Constructing the branch parameter at stateless proxies

From: [email-masked]
Date: Wed, 4 Dec 2002 17:49:32 +0530

Hi Robert,
     Here's one issue i could think of:
Insertion of branch parameter in Via header has been
mandatory for proxies all along. However, for UA's it
became mandatory only from bis-06 onwards. So if we
have a pre-bis-06 UA sending a request to a stateless
proxy (i.e. first hop is a SLP), the proxy would end
up forwarding it without a branch parameter. Ofcourse,
things would still work fine at the next stateful hop.
But, by not inserting a branch parameter, the SLP would
not be compliant to the spec. (Proxies MUST insert a
branch).

     This would happen only if a SLP is at the first
hop from such a UA. Thereafter, even if the request
loops or spirals through, the SLP would end up adding
different branches by following your approach. So we
could special-case this with a simpler logic so that
if the SLP doesn't see a branch in the topmost Via,
it could insert a simple one (concatenating the
Tags-CallId-CseqNum for example).

Subhash Nayak
Hughes Software Systems
http://www.hssworld.com

Robert Sparks <[email-masked]> on 12/03/2002 10:05:01 PM

To:   [email-masked]
cc:    (bcc: Subhash Ullal Nayak/HSSBLR)

Subject:  [Sip] Constructing the branch parameter at stateless proxies

This list has seen a couple of requests to clarify the language in
RFC 3261 concerning how a stateless proxy creates a branch identifier.

The current text requires uniqueness, dependency on route decision
affecting parameters and care to be sure that those parameters are
retransmission invariant. It goes on to recommend a hash over a
set of fields (this set has been the subject of the requests for
clarification).

I think there's a much simpler solution. The purpose of this
branch parameter is to act as a transaction identifier. Who
cares about this identifier? Only the stateful elements at
each end of the transaction. Any stateless proxies between
these elements don't use that identifier in any of their
decisions, so I assert that it is not useful to change it
as it crosses the stateless proxy.

I propose, then, that a stateless proxy simply copy
the branch parameter from the topmost Via header field
value it receives into the Via header field value it adds
to the request.

I don't believe it matters that this parameter contain the
magic cookie. If it doesn't, the next stateful hop will use
the 2543-style transaction identifiers provided by the sending
stateful element. The stateless elements are by definition
transaction transparent.

So - can anyone construct a scenario where this doesn't
function correctly? If not, we can remove several convoluted
paragraphs from the spec and replace them with a very simple
couple of sentences.

RjS

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip