22 Jun
2016
22 Jun
'16
7:45 a.m.
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........@192.168.10.245>;tag=as42745abe.
To:
<sip:+31........@192.168.10.246>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-f67d.
Call-ID: 576349c40a7cb77a06230e181831672d@192.168.10.245:5060.
CSeq: 102 INVITE.
Contact: <sip:06........@sip.example.net>,
<sip:06........@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........@192.168.10.245>;tag=as13f23689.
To:
<sip:+31........@192.168.10.246>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-b5fe.
Call-ID: 336a16912db412d418f7f7495e2574f5@192.168.10.245:5060.
CSeq: 102 INVITE.
Contact: <sip:accountname@sip.example.net>,
<sip:06........@sip.example.net>;q=0.01,
<sip:06........@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