Summary:ASTERISK-19558: SIP INVITE header is broken
Reporter:tootai (tootai)Labels:
Date Opened:2012-03-19 09:03:14Date Closed:2012-03-19 13:56:37
Versions:10.2.1 Frequency of
Environment:Debian 6.0 linux kernel 2.6.32-5-amd64Attachments:
Description:When passing a call to one of our peers, in debug mode we see:

Reliably Transmitting (no NAT) to xxx.xxx.xxx.xxx:5060:
INVITE sip:0000033123456789,120,T@xxx.xxx.xxx.xxx SIP/2.0
Via: SIP/2.0/UDP;branch=z9hG4bK553b4527
Max-Forwards: 70
From: "TOOTAi" <sip:0033123456789@>;tag=as3f695fdb
To: <sip:0000033123456789,120,T@>
Contact: <sip:0033368460088@>

and call is ended by peer with 400 "Bad Request". Indeed, you can see that INVITE and TO headers contains, the whole dial string wich include dial time and dial options!

Dialplan command is

exten => _XXX.,1,Dial(SIP/${tmpGW}/${tmpPR}${DIALEDNUMBER},120,${DIAL_OPTIONS})

- tmpGW is [myPeer] definition in sip.conf without brakets []
- tmpPR is 00000
- DIALEDNUMBER is 33123456789

which reflect the 0000033123456789,120,T we see in INVITE and To headers.

Comments:By: tootai (tootai) 2012-03-19 09:59:48.142-0500

I got it. My dial command is exactly

exten => s,1,Set(__CALLED_CHANNEL="SIP/${tmpGW}/${tmpPR}${DIALEDNUMBER},120,${DIAL_OPTIONS}")
exten => s,n,macro(DialCHANNEL)

exten => s,1,Dial(${CALLED_CHANNEL})

If I remove the double quotes when setting CALLED_CHANNEL variables it's working. In my dialplan, when a call failed in CONGESTION or CHANUNAVAIL, I set up a new CALLED_CHANNEL the same way, using double quotes and other peer definition. The call using this second setup (even the third as each call has 3 attemps to pass using 3 different peers) doesn't fail, INVITE and TO headers are OK.

This dialplan is perfectly working in asterisk 1.4 and 1.6


By: Matt Jordan (mjordan) 2012-03-19 10:33:21.952-0500

This appears to be the correct behavior.  Quotes are supposed to make the value in the variable evaluated as a single token - which is what the Dial application is doing.

From wiki.asterisk.org:


Although the description there doesn't necessarily show a complex scenario, note that it does state that "a comman does not terminate the field".

If you were including quotes around the value being set because some of the variables could include spaces, you probably should individually quote each variable that is evaluated.

By: tootai (tootai) 2012-03-19 13:08:09.014-0500

In Asterisk 1.4 and 1.6 (the production one we are running at this time) the same syntax is perfectly working. We installed a version, behavior is the same as 10.1 We don't remember if in 1.2 we already had our function implemented.

If it has to be considered as a bug of Asterisk 1.6 and previous versions ...


By: Matt Jordan (mjordan) 2012-03-19 13:56:30.228-0500

It probably was a bug in Asterisk 1.6 and previous - or at least, the behavior was not what was defined.  I haven't dug through the SVN logs to see what change in 1.8 corrected the behavior, so I'm not sure when it was corrected.  There's a chance that it was made somewhat recently (within the past year), which is why it was fixed in 1.8 but not in 1.6.x and previous.