[Serusers] branch parameter
Jiri Kuthan
jiri at iptel.org
Mon Feb 12 21:04:18 CET 2007
An Essay on Meaning of Branch in ACK
Table of Content
----------------
0. advance recommendation
1. history
2. semantics
3. bible reading
4. conclusion
0. advance recommendation
No UAS shall be confused by branch=0. If it is, file a bug report
against it. It shall match the end-to-end ACKs dialog-wise. Calculating
branch for e2e ACKs is pointless in a proxy server, but if a purist is
disturbed, turn sync_branch off.
1. history
Back in 2001, there was chaos and strong will to get out of it. Folks were
implementing RFC2543 and bombarding RFC authors with nasty questions, particularly
when trying to implement it. Most famous one being record-routing named later
as strict, however many other were troubling the gentle folks of the IETF.
One of those being horrible, horrible transaction matching based on
a compound key consisting of five header-fields and all of their
parameters. Those were causing interop issues as everyone else was
calculating it differently.
I was worried about it too as by that time any attempt to implement lazy
parsing failed because of the requirement to calculate transaction key
over almost all parts of a SIP message. Parsing, one of the most CPU-expensive
parts of the whole server, degraded performance badly. Then being with
dynamicsoft, we got together with Rosenberg (jdr) and Sparks (rjs), the latter
suggesting having a single-purpose transaction key (as opposed to
calculating it in a complicated way). jdr brought it through the IETF
in the bis-draft -08, -09 or so and put the "branch cookie" in it.
Badly enough, there is a small nit which was brought in a rush-rush change
in the bis-15 (or so?) version shortly before publication of RFC3261.
Suggestions for calculating the branch by a stateless proxy include
covering via-header field which consequently eliminates the chance
to carry out loop detection. (Via will be ALWAYS different even if
a request is spiralling heavily.)
2. semantics
Branch ID is there for transaction matching. That means that all requests
and replies belonging to the same transaction MUST have the same branch id.
The tricky part now is the end-to-end ACK (i.e., ACK sent in response to
a positive reply). This type of ACK is a kind of bastardized request in
that it seems to form the transaction logic (and has thus the same CSeq)
but it not part of the transaction state machine. From the transaction
view, it is a standalone stateless request associated with dialog. The
transaction machine is just unaware of it and passes it on to dialog
processing.
This is best demonstrated by a UAS. A UAS, when receiving the e-2-e ACK
MUST NOT look at the transaction id. Do you know why? (apart from the fact
that it is not really part of a transaction) ..... Because it is never
guaranteed to be the same as of the associated INVITE. The ACK might have
taken a completely different path. This is the case when the proxy servers
underway were not record-routing. Thus, ACK's branch can always have
a different value then INVITE's. Consequently, UASs MUST associate ACKs
with its information *dialog-wise*, i.e., by the triple callid, from-tag,
to-tag.
In summary, dear reader, transaction matching does not make sense for e2e
ACKs and consequently use of branch value in those is meaningless too.
3. bible reading
see Michael's quotations from the Holy Text.
annotations:
It is appears that in the literal sense of 8.1.1.7 (and 16.6's reference
to it) there is a violation of RFC when the cookie is missing. In a court,
one could possibly argue that there is no sense in it (see point 2.) for
e-2-e ACKS.
At 20:22 12/02/2007, Michal Matyska wrote:
>It takes me ages too. I've to check the RFC due to the fact, that my UAS
>was rejecting ACK with branch=0 and the result of the digg is, that I'm
>not sure whether is it correct to use it at all.
>
>If I skip the requirement in 8.1.1.7 Via:
>
> The branch ID inserted by an element compliant with this
> specification MUST always begin with the characters "z9hG4bK". These
> 7 characters are used as a magic cookie (7 is deemed sufficient to
> ensure that an older RFC 2543 implementation would not pick such a
> value), so that servers receiving the request can determine that the
> branch ID was constructed in the fashion described by this
> specification (that is, globally unique). Beyond this requirement,
> the precise format of the branch token is implementation-defined.
>
>then in 17.2.3 Matching Requests to Server Transactions we can read:
>
> If the branch parameter in the top Via header field is not present,
> or does not contain the magic cookie, the following procedures are
> used. These exist to handle backwards compatibility with RFC 2543
> compliant implementations.
>
> The INVITE request matches a transaction if the Request-URI, To tag,
> From tag, Call-ID, CSeq, and top Via header field match those of the
> INVITE request which created the transaction. In this case, the
> INVITE is a retransmission of the original one that created the
> transaction. The ACK request matches a transaction if the Request-
> URI, From tag, Call-ID, CSeq number (not the method), and top Via
>* header field match those of the INVITE request which created the
> transaction, and the To tag of the ACK matches the To tag of the
> response sent by the server transaction. Matching is done based on
> the matching rules defined for each of those header fields.
> Inclusion of the tag in the To header field in the ACK matching
> process helps disambiguate ACK for 2xx from ACK for other responses
> at a proxy, which may have forwarded both responses (This can occur
> in unusual conditions. Specifically, when a proxy forked a request,
> and then crashes, the responses may be delivered to another proxy,
> which might end up forwarding multiple responses upstream). An ACK
> request that matches an INVITE transaction matched by a previous ACK
> is considered a retransmission of that previous ACK.
>
>Note the sentence marked by * (hope the formatting will sustain) - if
>the branch is not present os does not contain the cookie (true for
>branch=0).... top Via header field match those of the INVITE.... we have
>branch id which does not start with the cookie - shall we use the branch
>id for the matching or not? As I understand the text, we use the Via
>header with the branch id, so it won't ever match the INVITE.
>
>I'm looking forward to your comments.
>OTOH, setting sync_branch=0 has helped (CVS head version).
>
>Michal
>
>
>On Wed, 2007-02-07 at 14:41 +0100, Jiri Kuthan wrote:
>> At 16:58 18/12/2006, Martin Hoffmann wrote:
>> >Jiri Kuthan wrote:
>> >> At 17:05 17/12/2006, Kapil Dhawan wrote:
>> >>
>> >> > I am using RTC/1.2 library and its not generating branch parameter.
>> >>
>> >> too bad, most implementation can deal with it in backw2ards compatibility mode
>> >> but clients should no longer generate such branch. I would be looking for
>> >> a more up-to-date stack if I was you.
>> >
>> ><evil>
>> >Ever used forward() in SER?
>> ></evil>
>>
>>
>>
>> sorry -- it takes me ages to answer. -jiri
>>
>> forward.c:
>>
>> /* calculate branch for outbound request; if syn_branch is turned off,
>> calculate is from transaction key, i.e., as an md5 of From/To/CallID/
>> CSeq exactly the same way as TM does; good for reboot -- than messages
>> belonging to transaction lost due to reboot will still be forwarded
>> with the same branch parameter and will be match-able downstream
>>
>> if it is turned on, we don't care about reboot; we simply put a simple
>> value in there; better for performance
>> */
>> if (syn_branch ) {
>> *msg->add_to_branch_s='0';
>> msg->add_to_branch_len=1;
>> } else {
>>
>> main.c
>>
>> /* shall use stateful synonym branches? faster but not reboot-safe */
>> int syn_branch = 1;
>>
>>
>>
>> --
>> Jiri Kuthan http://iptel.org/~jiri/
>>
>> _______________________________________________
>> Serusers mailing list
>> Serusers at lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
More information about the sr-users
mailing list