-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 telles@devel.it TI Manager Devel-IT - http://www.devel.it ============================================
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:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 telles@devel.it TI Manager Devel-IT - http://www.devel.it ============================================ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDJbvNiLK8unYgEMQRAoATAJwJSLGiN1/XuAUk2aVm4rm5oGD00ACfYJf0 XbL8Vv4unK6U3j974UOtYU0= =gZzI -----END PGP SIGNATURE-----
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 telles@devel.it 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 telles@devel.it TI Manager Devel-IT - http://www.devel.it ============================================
_______________________________________________ Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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 telles@devel.it 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 telles@devel.it TI Manager Devel-IT - http://www.devel.it ============================================
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDKEGhiLK8unYgEMQRAlOHAJ4ufRDMaOizWX5TIsdN0aL5WDDypwCdEOZv GD+1ajtmD7JlabMMG7K0QS4= =YkTR -----END PGP SIGNATURE-----
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-----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 telles@devel.it 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 telles@devel.it 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 telles@devel.it 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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 telles@devel.it 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 telles@devel.it 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 telles@devel.it 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
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDMWTpiLK8unYgEMQRAq3xAJ9mfLKD+qBwdLm5+6O6qIL8tG9r1gCcCS/o X8DVzc9VnK7to235pJ88pwA= =jbFh -----END PGP SIGNATURE-----
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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 telles@devel.it 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 telles@devel.it 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 telles@devel.it TI Manager Devel-IT - http://www.devel.it ============================================
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-
Bogdan-Andrei Iancu -
reticent -
Rodrigo P. Telles -
Tavis P