[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sip-implementors
Subject:    Re: [Sip-implementors] Repost: Via branch calculation
From:       Robert Sparks <rsparks () dynamicsoft ! com>
Date:       2003-06-20 13:56:46
Message-ID: 1056117405.924.44.camel () RjS ! localdomain
[Download RAW message or body]

Well, you can only do what you can do. As I noted before,
stateless proxies are very hard to get right, and its this
kind of edge condition that makes them hard.

The suggested algorithm does not meet the normative requirements
on the branch parameter value for this edge case, so you can't
use it. You can try to find a different algorithm. I'm not convinced
a correct algorithm exists, though I imagine you can build something
that only breaks under truly degenerate scenarios and you might deem
it "good enough".

Or you can decide that you'll preserve the transaction identifiers 
the stateful thing in front of you provided, even if that identifier
includes no branch parameter - the stateful thing behind you
is much better equipped to deal with it (that's what I currently
think people should implement and the direction I expect the spec
to take). 


RjS


The definition of the transaction identifiers changed
On Fri, 2003-06-20 at 01:03, sunayak@hss.hns.com wrote:
> Hi Robert,
>      Thanks for your response. Yes, i recall the
> discussions on the Via branch problem and your mail
> on this list explaining that things would work fine
> if stateless proxies simply copied the branch from
> the incoming request.
>      But there's a potential RFC violation in the
> following case: if the stateless proxy receives a
> request from a pre-bis-06 UA, then the topmost Via
> header will not have a branch parameter ("branch"
> insertion for UA's became mandatory only in bis-06,
> and i guess there are quite a few pre-bis-06
> implementations in existence). In this case, the
> stateless proxy would not insert a branch even though
> insertion of branch is a "MUST" requirement of the RFC...
> How do we get around this ?
> 
> Subhash.
> Hughes Software Systems
> http://www.hssworld.com
> 
> 
> 
> 
> 
> 
> Robert Sparks <rsparks@dynamicsoft.com> on 06/16/2003 07:42:24 PM
> 
> To:   Subhash Ullal Nayak/HSSBLR
> cc:   sip-implementors@cs.columbia.edu
> 
> Subject:  Re: [Sip-implementors] Repost: Via branch calculation
> 
> 
> 
> 
> There are more problems than just the To tag here. See
> http://bugs.sipit.net/sipwg/show_bug.cgi?id=659
> and
> http://bugs.sipit.net/sipwg/show_bug.cgi?id=680
> 
> Bug 680 basically captures the outcome of a discussion
> of the issue on the SIP list. We couldn't find anything
> that breaks if a stateless proxy just duplicates the
> branch-id it receives. The transaction relationship is
> between two stateful elements - any stateless elements
> between them have no reason to muck with transaction
> identifiers.
> 
> RjS
> 
> btw - there are some more subtle issues with trying to
> build stateless proxies. For instance, you cannot
> retarget a request based on a DNS lookup statelessly
> since the lookup might generate different results
> for a retransmitted request. If you are building one
> of these beasts, be very careful with _anything_ that
> might affect routing of a retransmission.
> 
> 
> On Mon, 2003-06-16 at 06:19, sunayak@hss.hns.com wrote:
> > Hi,
> >      Reposting my query as i did not see any
> > responses. If this is a bug in the spec, it should
> > have been caught during one of the SIPiTs. Or is
> > it that SLPs are using the To addrspec rather than
> > the To tag...
> >
> > Subhash Nayak
> > Hughes Software Systems
> > http://www.hssworld.com
> >
> >
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > Hi,
> >      I have a very basic doubt w.r.t. the Via branch
> > computation by a stateless proxy (SLP). Consider the
> > following setup:
> >
> > stateful  ---->  stateless   ----> stateful
> > entity(A)        proxy(SLP)        entity(B)
> >
> > In this setup, let the stateful entity (A) be a pre-bis-05
> > compliant device (it could be a UA or a proxy). Hence it
> > does not insert the magic cookie in the Via branch that
> > it inserts.
> >
> > Now, for every request that the SLP proxies, it would
> > insert a Via header with a branch computed as described
> > in the recommended algorithm of Section 16.11 :
> > "......the first component of the branch ID is
> > computed as a hash of the topmost Via, the tag in the
> > To header field, the tag in the From header field, the
> > Call-ID header field, the CSeq number (but not method),
> > and the Request-URI from the received request."
> >
> > How will the above work in the case of an INVITE-4xx-ACK
> > scenario ? The initial INVITE will not contain a To-tag
> > whereas the ACK to the non-2xx will contain a To-tag.
> > If the SLP uses the recommended algorithm, it will end
> > up generating a different Via branch for the INVITE and
> > the ACK thus botching up the transaction matching logic
> > at the next stateful entity (B).
> >
> > I know i'm missing something trivial, but what ???!!!
> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >
> >
> >
> >
> >
> >
> >
> > This message is proprietary to Hughes Software Systems Limited (HSS) 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.  HSS 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
> > Sip-implementors@cs.columbia.edu
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> 
> 
> 

[prev in list] [next in list] [prev in thread] [next in thread]