[Home]

Summary:ASTERISK-11722: [patch] Can't pickup if pickupcode include #
Reporter:Igor Goncharovsky (igorg)Labels:
Date Opened:2008-03-26 04:34:16Date Closed:2008-07-01 09:21:49
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug12299.txt
( 1) bug12299-11062-v2.patch
( 2) invite_uri_decode.patch
Description:This issue is similar to ASTERISK-1062681

I have 'pickupexten = ASTERISK-39' in features.conf and when dialed notice:

[Mar 26 15:35:15] NOTICE[14791]: chan_sip.c:16484 handle_request_invite: Call from '102' to extension '%2343' rejected because extension not found.

If change 'pickupexten = %2343' but it is unexpected behavior.

Also I need to clear one thing: extension and all codes in features.conf is escaped strings or no? Current code for incoming SIP check for both escaped and unescaped extensions. And I not sure that it is right.

My patch looks only looks for unescaped strings in extensions.conf.
Also I'll correct log message on line 16460, that always print escaped exten.
Comments:By: Igor Goncharovsky (igorg) 2008-03-26 04:37:42

Sorry for not correct filled bugreport:

Category: Channels/SIP/General
Asterisk Version: SVN
SVN Branch: trunk
SVN Revision: 110831
By: Olle Johansson (oej) 2008-03-26 07:54:06

Try with "pedantic=yes" in sip.conf.
By: Joshua C. Colp (jcolp) 2008-03-26 09:02:49

Please give oej's request a go and report back.
By: Igor Goncharovsky (igorg) 2008-03-26 10:53:25

I can test it only tomorrow, but obviously it will work because of this code after variable definition:

if (pedanticsipchecking)
ast_uri_decode(tmp);
uri = get_in_brackets(tmp);


I think it is not right solution for this situation, because as of RFC SIP URI is always escaped string. I do not understand why in this situation we need enabled 'pedantic' in SIP for unescape this. Is decoding of URI cause some problem?
By: Olle Johansson (oej) 2008-03-26 10:58:22

Why is under pedantic is historic, but that's just the way it is. Always enable pedantic and you'll be much happier... Contact me on IRC if you want to discuss this.
By: Olle Johansson (oej) 2008-03-27 03:31:53

re-open since I realize after discussion with IgorG that the decoding doesn't work properly here.
By: Olle Johansson (oej) 2008-03-27 04:48:05

I did not notice IgorG's patch earlier and we ended up with more or less the same patch. Let's move forward.

Apologiees to IgorG, I wasn't trying to be rude. Just missed it. Sorry.
By: Igor Goncharovsky (igorg) 2008-03-27 05:11:04

Oej, patch work. Also I upload my patch with one fixed log message that output exten escaped non-human-readable.

Before:
[Mar 27 16:08:24] NOTICE[16291]: chan_sip.c:16448 handle_request_invite: Call from '102' to extension '%238555' rejected because extension not found.

After:
[Mar 27 16:08:24] NOTICE[16291]: chan_sip.c:16448 handle_request_invite: Call from '102' to extension 'ASTERISK-8319' rejected because extension not found.
By: Jason Parker (jparker) 2008-03-28 17:00:17

Committable?
By: Igor Goncharovsky (igorg) 2008-04-01 05:04:00

I think that yes, my patch identical to oej one. Only added decode for exten in log message.
By: Jason Parker (jparker) 2008-05-01 15:27:10

Is this at all related to ASTERISK-10156 which was recently fixed?  I wonder if the same fix would apply.
By: Igor Goncharovsky (igorg) 2008-05-01 22:40:17

No, in this issue # in *incoming* message and already escaped to %23. Fix from ASTERISK-10156 won't fix this.
By: Digium Subversion (svnbot) 2008-07-01 09:20:27

Repository: asterisk
Revision: 126899

U   branches/1.4/channels/chan_sip.c

------------------------------------------------------------------------
r126899 | oej | 2008-07-01 09:20:08 -0500 (Tue, 01 Jul 2008) | 8 lines

Handle escaped URI's in call pickups. Patch by oej and IgorG.

Reported by: IgorG
Patches:
     bug12299-11062-v2.patch uploaded by IgorG (license 20)
Tested by: IgorG, oej
(closes issue ASTERISK-11722)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=126899