[SR-Users] behaviour of uac_redirect module

[Daniel-Constantin Mierla]

On 17/06/16 15:12, Dirk Teurlings - Signet B.V. wrote:
> Hi,
>
> Testing with latest stable 4.4 Kamailio at the moment, and running into
> the following issue.
>
> I have a setup that sends a 302 to do a Moved Temporarily to another
> extension. To update the Contact header accordingly, I use the
> get_redirects function in the failure_route.
>
> get_redirects('*', 'Redirects')
>
> This results in the following packet
>
>
> U 192.168.10.246:5060 -> 192.168.10.245:5060
> SIP/2.0 302 Moved Temporarily.
> Via: SIP/2.0/UDP
> 192.168.10.245:5060;branch=z9hG4bK40b58e09;rport=5060;received=192.168.10.245.
> From: "+31........" <sip:+31........ at 192.168.10.245>;tag=as42745abe.
> To:
> <sip:+31........ at 192.168.10.246>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-f67d.
> Call-ID: 576349c40a7cb77a06230e181831672d at 192.168.10.245:5060.
> CSeq: 102 INVITE.
> Contact: <sip:06........ at sip.example.net>,
> <sip:06........ at sip.example.net>;q=0.01.
> Server: sip.example.net.
> Content-Length: 0.
> .
>
>
>
> This works, but I don't want ACC to account for anything, so I tried:
>
> get_redirects('*')
>
> But this results in the following packet
>
>
>
> U 192.168.10.246:5060 -> 192.168.10.245:5060
> SIP/2.0 302 Moved Temporarily.
> Via: SIP/2.0/UDP
> 192.168.10.245:5060;branch=z9hG4bK185f4fdd;rport=5060;received=192.168.10.245.
> From: "+31........" <sip:+31........ at 192.168.10.245>;tag=as13f23689.
> To:
> <sip:+31........ at 192.168.10.246>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-b5fe.
> Call-ID: 336a16912db412d418f7f7495e2574f5 at 192.168.10.245:5060.
> CSeq: 102 INVITE.
> Contact: <sip:accountname at sip.example.net>,
> <sip:06........ at sip.example.net>;q=0.01,
> <sip:06........ at sip.example.net>;q=0.01.
> Server: sip.example.net.
> Content-Length: 0.
> .
>
>
> Notice the extra accountname Contact, this results in a forward that
> doesn't work for the mediaserver. To me the documentation about the
> function states that there should be no difference between using it with
> or without accounting as far as SIP messages go.
>
>
> Is this a bug, or is this by design?
>
Looking quickly at the code, both versions of the functions are
executing the same inner function, but there can still be some
conditions on the reason parameter, so I need to dig in further.

However, I need to understand first what you actually do there:

  - you are getting a 302 from downstream
  - call get redirects to created new branches from the contacts of
received 302
  - don't forward the 302 to upstream, but generated a new 302 with
t_reply(...) to be sent upstream

Is it right? Because after a get redirects, typically follows a forward
and the 302 is absorbed locally.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com - http://www.kamailio.org
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda