Hi everybody,
just to bring some light into the "branch=0" issue.
1) If a request is statelessly forwarded and syn_branch is disabled (0
value), the branch will get the "0" value - that's done for
speed/efficiency reasons. If syn_branch is enabled, for the statelessly
requests will got into branch same value as they were statefully
forwarded - the branch building mechanism is the same, but the request
is stelessly forwarded. This is more expensive (as processing) but is
more RFC compliant and more save in case of reboot - it ensure
transaction consistency even if you have a reboot in the middle of the
transaction.
2) 200 OK ACKs are end-2-end statelessly forwarded (as RFC says). So, if
you call t_relay for an ACK, this is what will happen:
a) no syn_branch -> TM will match the ACK with the INVITE
transaction and will use the branch from there. If no transaction was
matched, the ACK will get a branch=0;
b) with syn_branch -> TM will still match the ACK with the INVITE
transaction, but disregarding the result, the ACK branch will be
re-calculated as for the INVITE.
Note that internally, TM forward the ACK in a stateless way!
So, what happens in your case (if syn_branch is disabled):
1) either you use stateless fwd for request -> all request will have
branch=0
2) either use stateful fwd and you receive and ACK that does not
match the INVITE transaction (due bogus headers), and by default, TM
tries to fwd it statelessly -> branch=0.
hope that this helps a bit.
The patch you mention is actually void (no changes), it's just a
recomandation to use syn_branch.
regards,
bogdan
Tavis P wrote:
A patch was just released that pertains to this issue
http://bugs.sip-router.org/browse/SER-44?page=history
Rodrigo P. Telles wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I posted the same issue in serusers list and nobody answers too.
Seems that you are right!
Bad for us.
regards.
- --
============================================
Rodrigo P. Telles <[EMAIL PROTECTED]>
TI Manager
Devel-IT - http://www.devel.it
============================================
reticent wrote:
I was one of the initial reporters of this "bug"
In my case the issue was the use of Strict routing in the ACK or BYE
message that somehow wasn't caught by the "loose_route()" statement.
The UAC sends the messages with a URI of the SER proxy.
I didn't get a very good reception to my request, i the feeling i got
was that it was passed off an as not important or uninteresting. In my
case i resolved the issue by upgrading the UAC that was sending the
ACK/BYE.
I've seen at least 5-6 people report this, with the varying responses
(mostly that there was no issue, when it looked to me that there
was). I hope someone who understands the necessary specifications
and also SER
would look into this and quash the issue once and for all (even if just
to diffinitively identify it)
I would be interested in spending some time to try and get to the
bottom
of the issue, i will dig up the data from previous emails this
afternoon
and see if i can assist.
Rodrigo P. Telles wrote:
Bogdan,
Fistrly, thanks for your answer!
Reading some old posts about 'branch=0' I found some one saying that
it happend
because SER forward statelessly, but I'm using "t_relay()" and I
suppose it's a
statefull function, does'n it?
I saw this question many times in serusers maillist but no one
answer it!
According with RFC3261 'branch=0' is not a valid branch ID (I know I
can use
syn_branch=0)!
Best regards.
--
============================================
Rodrigo P. Telles <[EMAIL PROTECTED]>
Diretor de Tecnologia
Devel-IT - http://www.devel.it
============================================
Bogdan-Andrei Iancu wrote:
Hi Rodrigo,
as I see in that email, the problem is actually a broken ACK which
doesn't match the INVITE transaction and statelessly loops on the
proxy
- when statelessly fwded, the ACK gets branch=0 param in VIA.
so, what is your problem? - the actually presents of branch=0 or
why it
gets there?
regards,
bogdan
Rodrigo P. Telles wrote:
Hi folks,
I've been experiencing some troubles with ACK's with branch=0.
I found a thread about it but I didn't find a 'solution' folowing
the
thread.
http://mail.iptel.org/pipermail/serdev/2005-April/004296.html
Can some one point me to the correct answer for that question?
Thanks in advance.
--
============================================
Rodrigo P. Telles <[EMAIL PROTECTED]>
TI Manager
Devel-IT - http://www.devel.it
============================================
____________________________________________
Users mailing list
Users@openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
