[Home]

Summary:ASTERISK-14914: Wrong handling of INVITE with Diversion tag when Asterisk has seen the callid before
Reporter:Örn Arnarson (orn)Labels:
Date Opened:2009-09-30 14:18:11Date Closed:2010-10-06 10:12:34
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) cli_output.txt
( 1) diversion-full.txt
Description:Same scenario as 15095, but on 1.6 this time with very different (worse) behaviour. Same hardware and operating system as that report.

When asterisk receives a call (via PSTN in this case), sends an INVITE to a SIP proxy, that SIP proxy adds a Diversion tag and sends it back to asterisk to get back to the PSTN, the call doesn't complete an asterisk complains with a peculiar error:
[Sep 28 15:41:24] WARNING[32316]: chan_sip.c:4224 create_addr: No such host: 5555555

5555555 is the number being forwarded to, and is nowhere specified as a destination host.

****** ADDITIONAL INFORMATION ******

The INVITE coming back from the SIP proxy after the Diversion tag has been added is attached to this case.

This invite never reaches the dialplan (verbosity level was 9), but rather asterisk just complains about "no such host".

As stated in description above, this only happens in this scenario:
PSTN->asterisk->SIP proxy+diversion->asterisk (and the destination would be PSTN, but it doesn't make it into the dialplan).

If the call comes in and goes out on a different asterisk, everything works fine:
PSTN->asterisk1->SIP proxy+diversion->asterisk2->PSTN

It seems, therefore, that the existence of the channel with this callid messes things up.
Comments:By: Leif Madsen (lmadsen) 2009-10-01 08:52:46

Could you please provide additional console output and debugging? If you enable the 'full' log while replicating this issue, then attach that log file here, that should give us pretty much everything.

We're looking for sip debug, sip history, and console output with debug enabled.
By: Örn Arnarson (orn) 2009-10-01 12:29:14

Added full debug at verobsity level 9 with SIP debugging enabled.
By: Stefan Schmidt (schmidts) 2010-10-04 15:23:10

sorry but it looks like your proxy doesnt do it right.
pending on rfc 5806 a sip proxy should send a 30x message back with the diversion header or create a new request (invite) with the diversion header, but your proxy does not change the caller-id,branch and from tag so asterisk thinks its a response not a request and the diversion header finally brakes this dialog.

do you still use kamilio like you said in the related issue?


By: Stefan Schmidt (schmidts) 2010-10-04 15:57:21

if possible could you please try 1.8.0_rc2 cause in 1.8 there is a response diversion handling included, and i just want to know if it will work if the same request just comes back with the diversion header in 1.8

thanks
By: Örn Arnarson (orn) 2010-10-04 17:31:42

I'll do the 1.8.0_rc2 test tomorrow if I can and report back to you.

Side-note; I recently updated the 1.4 case I created (https://issues.asterisk.org/view.php?id=15095) on accident instead of this one. There a call is re-routed to Asterisk to be sent back to PSTN with a prefix stripped, but no diversion header added and same behavior is observed.
By: Örn Arnarson (orn) 2010-10-06 06:08:50

Roughly the same behavior is observed in 1.8.0_rc2, with one difference; billsecs is correct now and no longer 0 for the second leg of the call.

Yes, kamailio is still being used. So pretty much a new branch has to be created along with a new from tag for Asterisk do deal with it the way I expect it to?
By: Stefan Schmidt (schmidts) 2010-10-06 06:23:23

ok thank you, so 1.8 handles the diversion header better than 1.6, as expacted.

i have talked to klaus darillion about this, how kamilio should handle this and we are still not sure whom wrong handling this is. In his opinion asterisk should handle all incoming invites as a new call but as i have understood the RFC a invite should not sent directly back to its origin server cause a proxy cannot create a new call, just forward it to another server. So a 302 Reply would be much better for this instead of sending an invite back to the origin.

i will talk to some other developers how asterisk "should" act in this situation.
By: Örn Arnarson (orn) 2010-10-06 06:51:24

Actually, either I misread the earlier reported 1.8 data or it isn't doing the same thing each time; I am redoing the tests and as far as I can see it is handling it the way I want it to now; it is not sending a CANCEL to the proxy anymore. I will keep on making tests and let you know.
By: Örn Arnarson (orn) 2010-10-06 07:13:09

I've tested it multiple times again and it seems like 1.8 is handling this correctly every time now -- it is handling the INVITE as a new call and not sending any CANCEL messages.

Here's what it looks like now:

Asterisk-------------------Proxy
  |---------INVITE A------->|
  |<-------100 Trying-------|
  |<--INVITE B w/diversion--|
  |-------180 Ringing------>|
  |<------180 Ringing-------|
  |---------200 OK--------->|
  |<--------200 OK----------|
  |-----------ACK---------->|
  |<----------ACK-----------|

So, as I said above, I have no idea whether I misread the earlier capture (or looked at the wrong one?) or what was going on, but my further testing shows this behavior every time (though once I saw a 482 Loop detected, but call processing was normal).


By: Stefan Schmidt (schmidts) 2010-10-06 07:40:25

thanks for your answer. could you please test the following.
with 1.8 set pedantic=no in sip.conf and see if it still works and with 1.6.2 set pedantic=yes and test if it would work then.

cause we are not sure if it has to do with the different diversion handling in 1.8 or with pedantic set to yes by default ;)

thank you
By: Örn Arnarson (orn) 2010-10-06 09:09:55

If I put pedantic=no, I see the same, old, behavior on 1.8. If I set pedantic=yes on 1.6, nothing changes, so it seems to be more than the default setting of pedantic=yes on 1.8.
By: Stefan Schmidt (schmidts) 2010-10-06 10:12:33

after talking to Kevin Fleming we close this cause it would be too expensive to change in 1.4/1.6.2 as it works in 1.8 as expected.

best regards

Stefan Schmidt