Hello,

On 5/17/10 7:49 AM, Juha Heinanen wrote:

Juha Heinanen writes:

...

another strange thing is, why the branch route is executed only once (for the first t_relay) although the script is calling t_relay() two times and t_on_branch() is called before each call?

this was my mistake in the script (there was condition that prevented the log message to be printed). branch route is correctly called both times.

still the main issue persists, i.e., how to get rid of the first branch to which relaying had failed. even if i add clear_branches() call to next_gw() call, the first branch is still there. as result the first gw to which relaying fails tried twice (first time when it is alone in the destination set and second time when it in the destination set together with the second gw).

is a second call of next_gw() in route block always appending a branch? or is updating the r-uri/dst-uri?

In this case when t_relay failed, transaction is created, probably the first branch is set in transaction structure, but to see what is its states, need to get into sources...

Cheers, Daniel

below is new syslog output, where log in branch route is now always active.

-- juha

May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1532]: added gw_uri_avp<1|1|00||lohi.tutpro.com|5060||1|320> with weight<3765048> May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1532]: added gw_uri_avp<1|1|00||sars.tutpro.com|||2|64> with weight<2645835> May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying INVITEsip:00358407058055@sars.tutpro.com;transport=tcp to gw May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [ut.h:295]: ERROR: uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request (-7) May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [t_fwd.c:1391]: ERROR: t_forward_nonack: failure to add branches May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: Relaying failed with result -478 May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1951]: appending branchsip:00358407058055@lohi.tutpro.com:5060 May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: found next gw<Contact: sip:00358407058055@sars.tutpro.com;transport=tcp, sip:00358407058055@lohi.tutpro.com:5060> May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying INVITEsip:00358407058055@sars.tutpro.com;transport=tcp to gw May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [ut.h:295]: ERROR: uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request (-7) May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying INVITEsip:00358407058055@lohi.tutpro.com:5060 to gw May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: Relaying succeeded with result 1 May 17 08:37:32 localhost /usr/sbin/sip-proxy[14394]: WARNING: No more gws for INVITEsip:00358407058055@sars.tutpro.com;transport=tcp fromsip:test@test.fi

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

daniel,

when i implemented serial forking next_contacts() function as part of tm module, i was able to simply do

struct cell *t;

t = get_t();

and then find out with test

if (!t || (t == T_UNDEFINED)) {

if transaction exists.

any pointer on how to do the same from lcr module? i guess i need to load tm api and call some tm function?

-- juha

On 5/17/10 5:47 PM, Juha Heinanen wrote:

Juha Heinanen writes:

...

any pointer on how to do the same from lcr module? i guess i need to load tm api and call some tm function?

i think i was able to figure this out. the corresponding tm api function is t_gett().

yes, t_gett() is the way. For the reference, if someone needs to play with tm api, looking at tmx module is a good example, since it uses couple of them. also k sl module uses transaction detection for send_reply().

so i went and changed next_gw() implementation so that if no transaction exists, it rewrites request uri and if it exists, it clears possible old branches and appends a new one.

still next_gw() does not work as it should, i.e., second next_gw() call after failing t_relay() results in destination set with two sip uris (the first one and the second one).

then i went and added some more debug to script:

   # relay the request
   if (t_relay()) {
    xlog("Relaying succeeded with result $rc\n");
	exit;
} else {	
    xlog("Relaying failed with result $rc\n");
    if (t_check_trans()) {
	    xlog("Transaction exists\n");
    } else {
       xlog("Transaction does not exist\n");
    };
};

what happens now is that execution of the script stops at t_check_trans() test, i.e., nothing gets printed to syslog after this:

May 17 18:26:09 localhost /usr/sbin/sip-proxy[30400]: ERROR: Relaying failed with result -478

even if t_check_trans() would not be a proper function to call at this point, i don't understand why it does not return.

t_check_trans() returns 0 if transaction exists, iirc, to absorb retransmission.

anyway, then i then went and changed in above t_check_trans() to t_lookup_request() and execution of the script went on and printed this:

May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: INFO: Relaying INVITEsip:00358407058055@sars.tutpro.com;transport=tcp to gw May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: tm [ut.h:295]: ERROR: uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request (-7) May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: tm [t_fwd.c:1391]: ERROR: t_forward_nonack: failure to add branches May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: Relaying failed with result -478 May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: Transaction exists May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: ERROR: Calling next_gw() May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: ERROR: found next gw<Contact: sip:00358407058055@sars.tutpro.com;transport=tcp, sip:00358407058055@lohi.tutpro.com:5060> May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: INFO: Relaying INVITEsip:00358407058055@sars.tutpro.com;transport=tcp to gw ...

so even if t_relay() failed with result -478, transaction was created. as result, next_gw() thought that it must now append a new branch instead of rewriting request uri, which resulted in trying the first gw the second time.

i don't understand, how it is possible that transaction was created, but request uri was not marked as used. also, i don't understand how i can ever get this to work, because i don't have no way to know if i should rewrite request uri or append a branch.

I haven't got into this config situation yet. I will try to look into sources, but might take a bit since I travel. I will ping Andrei, maybe he can give a hint faster.

Cheers, Daniel

andrei, are you around? perhaps you can shed some light on this or better yet implement opensips behavior about which i posted a request to the tracker, which would allow me always just to rewrite request uri and be done with it.

-- juha

---

sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

Andrei Pelinescu-Onciul writes:

...

i don't understand, how it is possible that transaction was created, but request uri was not marked as used. also, i don't understand how i can ever get this to work, because i don't have no way to know if i should rewrite request uri or append a branch.

This happens because the request uri was not really used (adding a branch with it failed).

You could either check the return code and if

1. $? is E_BAD_ADDRESS or E_NO_SOCKET rewrite the uri
2. $? is E_SEND append a branch
3. all other cases for $? <0 exit.

or see below.

andrei,

i want to do that inside next_gw()/next_contacts() functions, not in the script. could it be somehow possible to check from the branch structure (dset.h/c) if request-uri is still unused? would get_branch_iterator(void) and next_branch() or get_branch() work although they seem to be very heavy means.

As far as I understood the osips behaviour was only for failure route.

may be, but it would be simpler still if i could set request-uri in any block, i.e., setting of request-uri always clears possible existing request uri and possibly existing branches. after that, more branches can be added by append_branch() before calling t_relay(), which always operates on request-uri and the possible branches.

Anyway there is a simple change that would allow rewriting only the request uri and having t_relay() add new branches. However it will work only if append_branch() is not used in the same time (if append_branch() is used and this is not the first t_relay() call, only the branches added by append_branch() will be used) and will hide mistakes like calling t_relay() twice without changing anything (e.g. t_relay(); t_relay() will result in 2 branches with the same uri and destination, instead of the current behaviour which is 1 branch and an error logged).

that sounds too complicated and risky. would the change that i suggest in above be more difficult to implement?

-- juha

On May 21, 2010 at 14:23, Juha Heinanen jh@tutpro.com wrote:

Andrei Pelinescu-Onciul writes:

...

...

i don't understand, how it is possible that transaction was created, but request uri was not marked as used. also, i don't understand how i can ever get this to work, because i don't have no way to know if i should rewrite request uri or append a branch.

This happens because the request uri was not really used (adding a branch with it failed).

You could either check the return code and if

1. $? is E_BAD_ADDRESS or E_NO_SOCKET rewrite the uri
2. $? is E_SEND append a branch
3. all other cases for $? <0 exit.

or see below.

andrei,

i want to do that inside next_gw()/next_contacts() functions, not in the script. could it be somehow possible to check from the branch structure (dset.h/c) if request-uri is still unused? would get_branch_iterator(void) and next_branch() or get_branch() work although they seem to be very heavy means.

No, they won't work. t_relay() will clear all the branches if it creates a transaction (even if it fails). Even if this wouldn't be the case it would still not possible to do the ruri check with the current code.

The only way would be either to get the transaction number of branches (t->nr_of_outgoings) previous to calling t_relay() and compare with the same number after that (if different you need to use append_branch(), else set new uri), or relay on checking ser_error (this is $rc or $? in the code).

...

As far as I understood the osips behaviour was only for failure route.

may be, but it would be simpler still if i could set request-uri in any block, i.e., setting of request-uri always clears possible existing request uri and possibly existing branches. after that, more branches can be added by append_branch() before calling t_relay(), which always operates on request-uri and the possible branches.

...

Anyway there is a simple change that would allow rewriting only the request uri and having t_relay() add new branches. However it will work only if append_branch() is not used in the same time (if append_branch() is used and this is not the first t_relay() call, only the branches added by append_branch() will be used) and will hide mistakes like calling t_relay() twice without changing anything (e.g. t_relay(); t_relay() will result in 2 branches with the same uri and destination, instead of the current behaviour which is 1 branch and an error logged).

that sounds too complicated and risky. would the change that i suggest in above be more difficult to implement?

It would be slightly more difficult (definitely not only 1 changed line). Basically we would need to remember if ruri is can be used for branches or not. On new message set ruri_is_new=1 (ruri_is_new being a new static var inside dset.c) and on clear_branches() set it to 0. Then change t_forward_non_ack() and use ruri_is_new instead of first_branch==0 for the first add_uac(). For failure route ruri_is_new should be set to 0. Each time a new uri is set, ruri_is_new should also be set to 1. Probably the same should be done if dst_uri is changed.

Andrei

andrei,

t_gett() returns pointer to the transaction (struct cell). would it be somehow possible to dig from that structure if the transaction still has some contacts in the destination set left unconsumed and if so, if there is the request uri branch still left?

-- juha

On May 26, 2010 at 18:09, Andrei Pelinescu-Onciul andrei@iptel.org wrote:

On May 25, 2010 at 19:05, Juha Heinanen jh@tutpro.com wrote:

...

andrei,

t_gett() returns pointer to the transaction (struct cell). would it be somehow possible to dig from that structure if the transaction still has some contacts in the destination set left unconsumed and if so, if there is the request uri branch still left?

If I understand correctly your use case (next_gw() called after t_relay() error, always adding only 1 branch and called form request_route) then yes: if t!= T_UNDEFINED and t!=0 and t->nr_of_outgoings!=0 => uri "consumed", add branch, else if t==0 or UNDEFINED => exit with error (something bad has happend, probably out-of-mem) else uri was bad => change ruri.

From failure route, always use append_branch.

Anyway I'll commit some code for the marking consumed ruris on some new branch soon (but would require extensive testing).

The branch is tmp/ruri_branch. I did only basic testing (serial forking from request and failure route). I tried to update all the modules that change r-uri, dst_uri or path to re-mark the r-uri as usable for forking (ruri_mark_new()), but it's possible that I've missed some.

Andrei

Juha Heinanen writes:

please merge ruri_branch to master and i'll commit my changes to lcr module. i can also take a look at next_contacts() function.

i tried to commit lcr changes to tmp/ruri_branch, but failed to do so.

i made a new branch called uri_branch from origin/tmp/ruri_branch and then commit the changes there. however, when i try to push the changes, i get errors:

jh@rautu:/usr/src/orig/sip-router/modules/lcr$ eg push xxxx@git.sip-router.org's password: error: src refspec tmp/ruri_branch does not match any. error: failed to push some refs to 'ssh://jh@git.sip-router.org/sip-router'

would be easier for me to commit to master.

-- juha

On May 27, 2010 at 16:15, Juha Heinanen jh@tutpro.com wrote:

Juha Heinanen writes:

...

please merge ruri_branch to master and i'll commit my changes to lcr module. i can also take a look at next_contacts() function.

i tried to commit lcr changes to tmp/ruri_branch, but failed to do so.

i made a new branch called uri_branch from origin/tmp/ruri_branch and then commit the changes there. however, when i try to push the changes, i get errors:

jh@rautu:/usr/src/orig/sip-router/modules/lcr$ eg push xxxx@git.sip-router.org's password: error: src refspec tmp/ruri_branch does not match any. error: failed to push some refs to 'ssh://jh@git.sip-router.org/sip-router'

I don't use eg, but shouldn't you use something like eg push --branch tmp/ruri_branch ?

With git I use git push origin HEAD:tmp/ruri_branch

Andrei