[asterisk-bugs] [Asterisk 0017892]: [patch] contact header does not get ast_uri_encoded value from p->exten, but dialplan does

Tue Sep 21 14:48:22 CDT 2010

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17892 
====================================================================== 
Reported By:                wdoekes
Assigned To:                jpeeler
====================================================================== 
Project:                    Asterisk
Issue ID:                   17892
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   trivial
Priority:                   normal
Status:                     acknowledged
Target Version:             1.6.2.15
Asterisk Version:           1.6.2.11 
JIRA:                       SWP-2116 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-08-20 04:49 CDT
Last Modified:              2010-09-21 14:48 CDT
====================================================================== 
Summary:                    [patch] contact header does not get ast_uri_encoded
value from p->exten, but dialplan does
Description: 
Hi, I have two asterisken, asterisk1 and asterisk2. (They run 1.6.2.11 and
1.6.2.8 respectively, but I'm fairly sure no sip encoding issues have been
fixed between those versions.)

With pedantic mode off, I get (url)decoded INVITE values, but they're not
re-encoded in the contact header. (I'm not sure about pedantic mode on, but
I'm guessing that will yield wrong results too.)

I was expecting to get no encoding/decoding at all with pedantic mode off,
but it seems I'm getting some:

(1) invite asterisk1 to asterisk2, triggered by:
Dial(126680004%40126680004 at asterisk2)

INVITE sip:126680004%40126680004 at asterisk2 SIP/2.0
Via: SIP/2.0/UDP x.x.x.1:5060;branch=z9hG4bK4a2faaf6
From: "209" <sip:209 at x.x.x.1>;tag=as39764467
To: <sip:126680004%40126680004 at asterisk2>
Contact: <sip:209 at x.x.x.1>

(2) response from asterisk2 to asterisk1, found by:
exten => _[0-9].@[0-9].,1,NoOp(got exten ${EXTEN})

SIP/2.0 100 Trying
Via: SIP/2.0/UDP x.x.x.1:5060;branch=z9hG4bK4a2faaf6;received=x.x.x.1
From: "209" <sip:209 at x.x.x.1>;tag=as39764467
To: <sip:126680004%40126680004 at asterisk2>
Contact: <sip:126680004 at 126680004@x.x.x.2>

In asterisk2, with pedantic mode off, I expect 126680004%40126680004 to be
found, but it matches 126680004 at 126680004. This could be a good thing,
because that's what I really wanted.

But, as you can see, the Contact header is wrong. This is to be expected,
because only with pedantic mode the encoding functions (should) get
triggered.

However, when checking static void build_contact(struct sip_pvt *p) {}, I
see no logic to ast_uri_encode p->exten if sip_cfg.pedanticsipchecking.

The non-encoded Contact poses a problem when trying to create the ACK on
asterisk1 as response to the 200 from asterisk2:

Capabilities: us - 0x8 (alaw), peer - audio=0x8 (alaw)/video=0x0
(nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x1
(telephone-event), combined - 0x1 (telephone-event)
Peer audio RTP is at port x.x.x.2:10060
list_route: hop: <sip:126680004 at 126680004@x.x.x.2>
[2010-08-20 11:08:01] WARNING[1580]: chan_sip.c:12259
__set_address_from_contact: Invalid host name in Contact: (can't resolve in
DNS) : '126680004 at x.x.x.2'
set_destination: Parsing <sip:126680004 at 126680004@x.x.x.2> for
address/port to send to
[2010-08-20 11:08:01] WARNING[1580]: chan_sip.c:9323 set_destination:
Can't find address for host '126680004 at x.x.x.2'

(In my case, this isn't a problem, as the Contact destination is the same
as the original destination, causing the set_destination to be a harmless
no-op.)
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0016329 chan_sip transforms %23 to # (UTF-8 iss...
====================================================================== 

---------------------------------------------------------------------- 
 (0127231) wdoekes (reporter) - 2010-09-21 14:48
 https://issues.asterisk.org/view.php?id=17892#c127231 
---------------------------------------------------------------------- 
issue17892_too_much_decoding.diff points to places where things are wrong:

Hunk https://issues.asterisk.org/view.php?id=2 undoes the Contact being decoded.
With that patched (pedantic mode
still off), the Contact header is unscathed, but the decoded extension is
still matched.

Hunk https://issues.asterisk.org/view.php?id=1 fixes that the original extension
is matched (123%40456 matches
exten 123%40456)

I'm unsure about the decode at https://issues.asterisk.org/view.php?id=3. And
https://issues.asterisk.org/view.php?id=4 is merely cosmetic.

Unpatched and without pedantic mode, asterisk-1.6.2.13 matches exten
123 at 456 when calling 123%2540456 (that's enc(enc("123 at 456")))).
Unpatched and with pedantic mode, it's even worse, because the uri is
already decoded (line 13443) and then the decoding continues.
(enc(enc(enc("123 at 456"))))

A bit of FYI. Hope it helps. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-09-21 14:48 wdoekes        Note Added: 0127231                          
======================================================================