[sr-dev] tsilo - t_append() uri

Daniel-Constantin Mierla miconda at gmail.com
Tue Sep 22 15:34:46 CEST 2015


Hello,

it was no longer about what tsilo stores internally, but what
lookup_to_dset() is given to search for new contact.

To explain with an example:

Call to sip:user at domain.

After lookup("location"), the r-uri of INVITE is changed to contact
address found in location table (let's say it was only one contact
there, which is sip:randomstring at deviceip:deviceport).

t_relay() is execute and transaction is created, with uas field holding
the INVITE with r-uri sip:randomstring at deviceip:deviceport.

After a while, a device for same user registers, if I call
ts_append(..., "sip:user at domain"), it finds the INVITE transaction to be
associated with sip:user at domain, but lookup_to_dset() is executed
internally by tsilo with the argument being the request from
Transaction->uas (and no explicit URI parameter). So the lookup is done
for sip:randomstring at deviceip:deviceport), because that is the r-uri in
T-uas reques. Obviously that will fail to find new contacts.

Hopefully I could expose the issue better now.

Cheers,
Daniel

On 22/09/15 15:14, Federico Cabiddu wrote:
> Hi,
> I'm not sure I fully understand the problem. See my comments inline
>
> On Tue, Sep 22, 2015 at 2:24 PM, Daniel-Constantin Mierla
> <miconda at gmail.com <mailto:miconda at gmail.com>> wrote:
>
>     Hello,
>
>     tsilo is not using the uri parameter for looking up location for new
>     destinations. It passes the uas request from transaction module to
>     registrar lookup_to_dset() function, so the r-uri from that
>     request is used.
>
>     However, there is at least one scenario that makes tsilo not working
>     properly:
>
>     - invite comes in
>     - lookup location finds a contact
>     - request is forwarded with a new r-uri (the contact of the location
>     record) -- t_relay() is used and trasaction created, r-uri stored for
>     uas is contact header
>     - a new registration comes and ts_append() is executed, failing to
>     find
>     contacts for r-uri in uas because the r-uri there can be anything
>     pointing to the first device found in location
>
>
> This happens because since
> commit 1e5bad019c450a003e812ee051d84134aad6c5f0, we are using the
> current uri to store the transaction. 
> That's why I was wondering (probably I have not been clear in my other
> mail :)) if, since now ts_store accepts uris as parameter, we still
> need this.
> In this case, the scenario you describe would work flawlessly and, if
> one need to store the transaction under a new ruri after some kind of
> message manipulation (like using alias etc) he can always call
> ts_store with the specific uri he wants to use.
> Am I missing something?

>
>  Some solutions can be found by creating transaction earlier, but not
>
>     easy to tackle always.
>
>     I think it would be better to just pass the uri parameter from
>     ts_append() to lookup_to_dset(). But I noticed that the uri can be
>     just
>     username if use_domain is 0, which makes things a little more complex,
>     because registrar/usrloc expect full sip uri.
>
>     The solution would be to 'force' always that the uri parameters for
>     tsilo functions are full SIP uri, and let the code extract only
>     username
>     when use_domain is 0. If someone has only the username in config,
>     it can
>     simply put the uri parameter as "sip:username at localhost" -- domain
>     will
>     be ignored anyhow.
>
>
>  Agree that this could avoid future headaches and provide more
> flexibility for other use cases. In this case, should we totally
> remove the dependency on usrloc "use_domain" parameter?
>  
>
>     Alternative, if the parameter is just username, built a temporary uri
>     for it before passing to lookup_to_dset().
>
>     I find first solution a bit better because the parameter for tsilo
>     functions is called uri and building an internal one can end up in
>     some
>     limitations if it is going to be something that requires tel: or sips:
>     or parameters such as instance.
>
>
> Agree.
>  
>
>     Any comments/suggestions?
>
>     Cheers,
>     Daniel
>
>
> Cheers,
>
> Federico 
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Book: SIP Routing With Kamailio - http://www.asipto.com
Kamailio Advanced Training, Sep 28-30, 2015, in Berlin - http://asipto.com/u/kat

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20150922/6a3c0284/attachment.html>


More information about the sr-dev mailing list