[sr-dev] Outbound summary

[Daniel-Constantin Mierla]

Hello,

On 8/9/12 4:42 PM, Peter Dunkley wrote:
> On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson wrote:
>> I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....

there is no final design yet, I assume, but if there is a need for 
[persistent] storage, I would not like to get rr or path dependent of db 
or other type of external storage. If the flow value carries the 
information needed for routing in the SIP message, then rr/path can be 
extended. Otherwise I think a new module to take care of storage 
overhead is recommended, either using internally rr/path or the other 
modules using it.

The fact is that these modules are used heavily, even in embedded 
devices, but at the moment outbound is not implemented at large in 
clients side (ie, few phones sending sip.instance and reg-id). So the 
'classic' usage is still the most important for some time.

Cheers,
Daniel


>
> My concern is just the amount of complex Kamailio configuration 
> required for something like Outbound.  It's likely to be very messy 
> and hard for people to use.  But if you think it is practical, I don't 
> have a problem trying it that way.
>
> There are going to be quite a number of (hopefully small) changes to 
> the existing modules (path, registrar, rr, and usrloc at least) anyway.
>
>   * The record_route() APIs need to be updated to make the userinfo
>     settable from kamailio.cfg (at least you can already add parameters)
>   * The add_path() APIs need to be updated to let parameters be added
>     (for example ";ob" - at least you can already set the userinfo)
>   * The logic to decide to use outbound for requests from clients
>     should be manageable as a route
>   * The logic to do the routing back to clients, sending the 430 etc,
>     should be manageable as a route
>   * Flow token generation/decode/validation is going to be tricky as
>     new APIs will be needed for at least base64 encode, base64 decode,
>     HMAC-SHA1-80 - and string manipulation in kamailio.cfg is a pain. 
>     Perhaps a set of flow-token specific APIs to wrapper all of these
>     things (in one of the utils modules) would be better?
>   * A new API will be required to determine whether a connection
>     exists (based on input of IP address, port, and protocol) - unless
>     trying to send the request and just catching/translating the error
>     to a 430 is OK
>   * I think the new lookup(), lookup_next_dest(), managing the AVPs
>     for this and removing bindings from the location table all do need
>     to be new functions in the registrar module
>
>
> Have I missed anything in that list?
>
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
>
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - http://asipto.com/u/katu
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - http://asipto.com/u/kpw

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20120809/b729d6b5/attachment.htm>