|Summary:||ASTERISK-12284: Call rejected with 403 when sending a call between two SIP gateways|
|Reporter:||Andre Sencioles (asenci)||Labels:|
|Date Opened:||2008-06-30 12:46:26||Date Closed:||2011-06-07 14:02:47|
|Environment:||Attachments:||( 0) 12957.patch|
( 1) 20080630-bug.dump
( 2) 20080701-sip_debug.txt
|Description:||I have two Asterisk servers, one acting as SIP/TDM gateway and another as IVR server.|
The issue happens when a SIP/TDM client calls the IVR and the call is bridged to another SIP/TDM client in the first server.
Client 1 dial to the IVR
Call enters Server A
Server A sends call to Server B
Server B presents the IVR to Client 1
Client chooses Client 2 in the IVR
Server B bridges the call back to the Server A (Client 2)
Call rejected with 403
Setting "fromuser=" in the "Server A" peer at Server B allows the call to be bridged back to Server A, but scramble Caller ID.
Tested with Asterisk versions 1.4.18, 1.4.19, 1.4.19 and 1.4.21, all with the same results.
|Comments:||By: Andre Sencioles (asenci) 2008-06-30 12:50:19|
Sent pcap dump from the invites sent by "Server B" to "Server A", with and without "fromuser=" set.
By: snuffy (snuffy) 2008-06-30 16:02:53
asencl.. you will also need to post a SIP DEBUG
By: Andre Sencioles (asenci) 2008-07-01 08:11:43
Sent sip debug at servers "A" (Magnesium) and "B" (Fluorine).
sip set debug peer "server AorB"
core set debug 99
By: Andre Sencioles (asenci) 2008-07-01 08:14:55
Forgot to send the details:
Using Zap channel 104 on server Magnesium (phone at my desk) to call 22229696 (IVR) at server Fluorine.
Choosen option 2 at the IVR.
Server Fluorine calls 22229670 at server Magnesium.
Server Magnesium declines with 403.
Tests done without "fromuser=" set.
By: Leif Madsen (lmadsen) 2008-11-20 17:15:20.000-0600
Sorry putnopvut, this seems like something that MAY be simple, and I closed a bug for you, so you get this one in its place ;)
By: Mark Michelson (mmichelson) 2008-11-25 17:45:05.000-0600
A quick look suggests that there is an authentication failure occurring which results in the 403. I haven't looked too deeply into this yet, though, so I'll see if I can come up with a more thorough explanation soon.
By: Mark Michelson (mmichelson) 2008-11-26 14:03:59.000-0600
The code doesn't provide any sort of debug messages to indicate why authentication failed, even though the function used to authenticate returns a reason. So this is going to be a bit tough to figure out just based on the information that I have.
What I'm going to do is to post a tiny patch which will print the return value from checking authentication credentials so that we can see the reason that the 403 was sent.
As another exercise, I'm curious to know if Fluorine can place calls to 22229670 under normal conditions. If not, then this may just be an authentication issue in your setup.
By: Mark Michelson (mmichelson) 2008-11-26 14:06:44.000-0600
I have uploaded 12957.patch to this issue. It simply enhances an existing NOTICE message in chan_sip.c
Please be sure that NOTICEs are logged somewhere and upload a trace from when this problem occurs.
By: Mark Michelson (mmichelson) 2008-12-17 14:23:11.000-0600
19 days with no response makes me think that this is something no longer affecting the reporter. I'm suspending this, but it may be re-opened if desired.