Hi! Yes, it is very important and for us! LCR module. If we get 6XX response from the first gateway, it is impossible to redirect request to any others gateways . We have very strange situation! If the first gateway (with the best priority for some distinations) due his reasons answer with 6XX it destroy lcr logic at all !!! (and we do not want to change this gateway because we have no problems with others destinations(and some others reasons))
please, change this tm behavior asap. Or if you can suggest something else (i mean some rows of config code) ?
thank you.
Why? doesn't it make sense to forward to some destination even if the
negative
reply is a 4XX or 6XX?
El Tuesday 03 June 2008 12:50:05 Igor Sidorov escribió:
Hi! Yes, it is very important and for us! LCR module. If we get 6XX response from the first gateway, it is impossible to redirect request to any others gateways . We have very strange situation! If the first gateway (with the best priority for some distinations) due his reasons answer with 6XX it destroy lcr logic at all !!! (and we do not want to change this gateway because we have no problems with others destinations(and some others reasons))
please, change this tm behavior asap. Or if you can suggest something else (i mean some rows of config code) ?
Hi, I'm sorry but this is not a OpenSer issue at all, OpenSer is RFc 3261 100% compliant in this aspect. I opened a bug for this 6XX issue and it's very well explained and closed:
https://sourceforge.net/tracker/?func=detail&atid=743023&aid=1968908...
I've also asked in sip-implemetors about this problem:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-June/019413.ht...
The conclusion is that no SIP device should reply a 6XX except if it knows that will break any parallel and serial forking. The problem is that many SIP devices (phones, gateways...) use a 6XX when they should use a 4XX.
The only solution is using a B2BUA and converting the 6XX to a 4XX.
Hi Igor,
I made a change yesterday - a new parameter in TM to control the 6xx behaviour: http://www.openser.org/docs/modules/1.4.x/tm.html#id2532936
This will solve your problem, but it is only in 1.4 (trunk) version.
Regards, Bogdan
Igor Sidorov wrote:
Hi! Yes, it is very important and for us! LCR module. If we get 6XX response from the first gateway, it is impossible to redirect request to any others gateways . We have very strange situation! If the first gateway (with the best priority for some distinations) due his reasons answer with 6XX it destroy lcr logic at all !!! (and we do not want to change this gateway because we have no problems with others destinations(and some others reasons))
please, change this tm behavior asap. Or if you can suggest something else (i mean some rows of config code) ?
thank you.
Why? doesn't it make sense to forward to some destination even if the
negative
reply is a 4XX or 6XX?
Hi! Thanks a lot! And, while, now in 1.3 I have changed the following... ....modules/tm/t_reply.c if (new_code>=700) { /* !!!!!! was --> new_code>=600!! */ /* this is a winner and close all branches */ which_cancel( Trans, cancel_bitmap ); picked_branch=branch; /* no more new branches should be added to this transaction */ Trans->flags |= T_NO_NEW_BRANCHES_FLAG; ...It works....... :-)))
Igor
Bogdan-Andrei Iancu wrote:
Hi Igor,
I made a change yesterday - a new parameter in TM to control the 6xx behaviour: http://www.openser.org/docs/modules/1.4.x/tm.html#id2532936
This will solve your problem, but it is only in 1.4 (trunk) version.
Regards, Bogdan
Hi Igor,
What you did is a dirty hack, but as you said, it works - better do a backport from the trunk version.
Regards, Bogdan
Igor Sidorov wrote:
Hi! Thanks a lot! And, while, now in 1.3 I have changed the following... ....modules/tm/t_reply.c if (new_code>=700) { /* !!!!!! was --> new_code>=600!! */ /* this is a winner and close all branches */ which_cancel( Trans, cancel_bitmap ); picked_branch=branch; /* no more new branches should be added to this transaction */ Trans->flags |= T_NO_NEW_BRANCHES_FLAG; ...It works....... :-)))
Igor
Bogdan-Andrei Iancu wrote:
Hi Igor,
I made a change yesterday - a new parameter in TM to control the 6xx behaviour: http://www.openser.org/docs/modules/1.4.x/tm.html#id2532936
This will solve your problem, but it is only in 1.4 (trunk) version.
Regards, Bogdan
-
Bogdan-Andrei Iancu -
Igor Sidorov -
Iñaki Baz Castillo