[SR-Users] header manipulation in locally generated SIP OPTIONS requests

[Olle E. Johansson]

On 10 Nov 2014, at 16:46, Klaus Feichtinger <klaus.lists at inode.at> wrote:

> Hello,
>  
> does kamailio offer any possibility for adding / replacing SIP headers in locally built SIP requests? In detail: SIP OPTIONS requests that are built by the DISPATCHER module for probing the configured targets. I have to extend these messages with "Accept" SIP header fields (which are marked with m* in RFC3261 - so they SHOULD be present), as the dispatcher target is requiring this information for answering these requests....
>  
> The event_route is principally accepting the append_hf() function and is adding the configured header fields. But the answer to that request (which is including these additional header fields) is confusing the dispatcher module. Dispatcher module is reacting with this ERROR message:
> DEBUG: dispatcher [dispatch.c:2406]: probing set #1, URI sip:10.10.10.10 
> DEBUG: dispatcher [dispatch.c:2345]: OPTIONS-Request was finished with code 500 (to , group 1) 
> ERROR: dispatcher [dispatch.c:2358]: Setting the state failed (, group 1) 
> 
> When I comment the textops functions out again and use the original OPTIONS messages, dispatcher is happy and knows the states of the probed targets.
>  
> Therefore, I´ll ask again: does kamailio offer any way for manipulating locally built SIP requests?

In some modules you can set the outbound proxy to point to yourself and then you can manipulate like any other message.

/O