[asterisk-dev] [Code Review] func_srv and explicit specification of destination for SIP outgoing INVITEs

[Russell Bryant]

> On 2010-04-07 12:22:48, Tilghman Lesher wrote:
> > /trunk/funcs/func_srv.c, lines 55-57
> > <https://reviewboard.asterisk.org/r/608/diff/2/?file=9146#file9146line55>
> >
> >     I would suggest allowing the service name as the ID.  This would permit you to get rid of the initiation query altogether, by checking to see if you have a result in your cache and doing the query if not; otherwise, return the particular result from the query cache.
> 
> Mark Michelson wrote:
>     This is certainly easy to accomplish, but I have two reasons to not want to do this, one contrived and one rational.
>     
>     Contrived reason: By doing as you suggested, it would not be possible to perform more than one lookup for the same service on a single call.
>     Rational reason: Consistency. We have two similar constructs in use with ENUMQUERY and ENUMRESULT, and DUNDIQUERY and DUNDIRESULT. My intention here was to mirror those constructs as much as possible.
> 
> Mark Michelson wrote:
>     Tilghman and I had a discussion offline and came to a conclusion that works as a compromise for both our views.
>     
>     SRVQUERY will return, as an ID, not an integer, but rather the name of the service being queried. Then, this gets passed as the ID to SRVRESULT.
>     SRVRESULT will then be "smart" enough to do the SRV lookup itself if results from a previous SRVQUERY could not be found.
>     
>     The result is that people who want to use SRVQUERY and SRVRESULT together can do so, but those who wish to bypass SRVQUERY and just use SRVRESULT on its own may also do so. I'll upload a new patch with this behavior shortly.

I don't really like this change that much.

Using the service as the ID means it is only possible to do a single lookup.  What if a dialplan author would like to be able to do the lookup more than once?  The results may not always be the same for each query.  Mark, you suggested this and I don't think it's a contrived example at all.


- Russell


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/608/#review1812
-----------------------------------------------------------


On 2010-04-07 15:28:47, Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/608/
> -----------------------------------------------------------
> 
> (Updated 2010-04-07 15:28:47)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> There are two interrelated changes here.
> 
> First, there is the introduction of func_srv. This adds two new read-only dialplan functions, SRVQUERY and SRVRESULT. They work very similarly to the ENUMQUERY and ENUMRESULT functions, except that this allows one to query SRV records instead. In order to facilitate this work, I added a couple of new API calls to srv.h. ast_srv_get_record_count tells the number of records returned by an SRV lookup. This number is calculated at the time of the SRV lookup. ast_srv_get_nth_record allows one to get a numbered SRV record.
> 
> Second, there is the modification to chan_sip that allows one to specify a hostname or IP address (along with a port) to send an outgoing INVITE to when dialing a SIP peer. This goes hand-in-hand with func_srv. You can query SRV records and then use the host and port from the results to dial via a specific host instead of what is configured in sip.conf.
> 
> 
> Diffs
> -----
> 
>   /trunk/channels/chan_sip.c 256421 
>   /trunk/funcs/func_srv.c PRE-CREATION 
>   /trunk/include/asterisk/srv.h 256421 
>   /trunk/main/srv.c 256421 
> 
> Diff: https://reviewboard.asterisk.org/r/608/diff
> 
> 
> Testing
> -------
> 
> I have written two external tests which exercise the individual components of this patch. They will be uploaded in a separate code review.
> 
> 
> Thanks,
> 
> Mark
> 
>