[Home]

Summary:ASTERISK-21148: [patch] - Asterisk use '(null)' in 'via' header and 'call-id' header when relaying SIP MESSAGE
Reporter:Zhi Cheng (chengzhicn)Labels:
Date Opened:2013-02-22 01:20:38.000-0600Date Closed:2013-03-08 14:34:58.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/Messaging
Versions:11.2.1 Frequency of
Occurrence		Constant
Related
Issues:
Environment:openwrt 12.09 betaAttachments:( 0) 700-sip_msg_send_via_fix.patch
( 1) debuglog
( 2) debuglog_newconfig
( 3) voip_newconfig.cap
( 4) voip.cap
Description:My setup:
csipsimple@android --> main server --> GSM gateway server(using chan_dongle)
192.168.0.83            192.168.0.1        192.168.0.213

Both servers are running asterisk 11.2.1. When a SMS arrived from GSM network on 192.168.0.213, that message will translate to SIP MESSAGE and passed through main asterisk server(192.168.0.1) to csipsimple, but when main asterisk server relaying the MESSAGE, the 'via' header is '(null)', cause csipsimple simply drop packet.


extensions.conf on 192.168.0.213
{noformat}
[mobile]
exten => sms,1,Noop(Incoming SMS from ${CALLERID(all)})
exten => sms,n,Set(MESSAGE(body)=${BASE64_DECODE(${SMS_BASE64})})
exten => sms,n,Set(ACTUALFROM=${CALLERID(num)})
exten => sms,n,Set(ACTUALFROM=${STRREPLACE(ACTUALFROM,+86)})
exten => sms,n,MessageSend(SIP:homemain, "${ACTUALFROM}" <${ACTUALFROM}>)
exten => sms,n,Hangup()
[mobilesms]
exten => _X.,1,NoOp(Send SMS To ${MESSAGE(to)} : ${MESSAGE(body)})
exten => _X.,n,Set(ACTUALTO=+86${CUT(CUT(MESSAGE(to),@,1),:,2)})
exten => _X.,n,DongleSendSMS(donglee180,${ACTUALTO},${MESSAGE(body)})
exten => _X.,n,Hangup()
{noformat}

sip.conf on 192.168.0.213
{noformat}
[homemain]
type=friend
host=192.168.0.1
fromdomain=192.168.0.213
directmedia=no
insecure=port,invite
qualify=yes
context=intern
dtmfmode=rfc2833
outofcall_message_context=mobilesms
{noformat}

dongle.conf on 192.168.0.213
{noformat}
[donglee180]
context=mobile
dtmf=relax
rxgain=4
txgain=0
audio=/dev/ttyUSB2
data=/dev/ttyUSB3
{noformat}

extensions.conf on 192.168.0.1
{noformat}
[outmobilesms]
exten => _X.,1,NoOp(Send SMS To ${MESSAGE(to)} : ${MESSAGE(body)})
exten => _X.,n,Set(ACTUALTO=${CUT(MESSAGE(to),@,1)})
exten => _X.,n,MessageSend(${ACTUALTO}@192.168.0.213, sip:"asterisk" <asterisk>)
exten => _X.,n,Hangup()
[inmobilesms]
exten => s,1,NoOp(Incoming SMS from ${MESSAGE(from)} : ${MESSAGE(body)})
exten => s,n,Set(ACTUALFROM=${CUT(MESSAGE(from),@,1)})
exten => s,n,Set(ACTUALFROM=${CUT(ACTUALFROM,:,2)})
exten => s,n,MessageSend(SIP:2204, "${ACTUALFROM}" <${ACTUALFROM}>)
exten => s,n,Hangup()
{noformat}

sip.conf on 192.168.0.1
{noformat}
[mobile-out]
type=friend
host=192.168.0.213
fromdomain=192.168.0.1
directmedia=no
insecure=port,invite
qualify=yes
dtmfmode=rfc2833
context=mobile
outofcall_message_context=inmobilesms
disallow=gsm
[2204]
type=friend
defaultuser=2204
secret=pass
host=dynamic
context=internmobile
dtmfmode=rfc2833
directmedia=no
nat=force_rport,comedia
mailbox=2204
outofcall_message_context=outmobilesms
{noformat}
Comments:By: Zhi Cheng (chengzhicn) 2013-02-22 01:25:01.305-0600

tcpdump result on main server(192.168.0.1)
By: Michael L. Young (elguero) 2013-02-22 09:59:23.862-0600

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Zhi Cheng (chengzhicn) 2013-02-22 12:47:33.251-0600

debug log attached
By: Michael L. Young (elguero) 2013-02-22 14:07:43.760-0600

It looks to me like you have a configuration problem.

From your logs:
{noformat}
[Feb 23 02:29:02] VERBOSE[13700][C-00000015] pbx.c:     -- Executing [s@inmobilesms:2] Set("Message/ast_msg_queue", "ACTUALFROM="10658487" <sip:10658487") in new stack
[Feb 23 02:29:02] DEBUG[13700][C-00000015] pbx.c: Evaluating 'ACTUALFROM' (from 'ACTUALFROM}' len 10)
[Feb 23 02:29:02] DEBUG[13700][C-00000015] pbx.c: Result of 'ACTUALFROM' is '"10658487" <sip:10658487'
[Feb 23 02:29:02] DEBUG[13700][C-00000015] pbx.c: Function result is '10658487'
[Feb 23 02:29:02] DEBUG[13700][C-00000015] pbx.c: Launching 'Set'
[Feb 23 02:29:02] VERBOSE[13700][C-00000015] pbx.c:     -- Executing [s@inmobilesms:3] Set("Message/ast_msg_queue", "ACTUALFROM=10658487") in new stack
[Feb 23 02:29:02] DEBUG[13700][C-00000015] pbx.c: Result of 'ACTUALFROM' is '10658487'
[Feb 23 02:29:02] DEBUG[13700][C-00000015] pbx.c: Result of 'ACTUALFROM' is '10658487'
[Feb 23 02:29:02] DEBUG[13700][C-00000015] pbx.c: Launching 'MessageSend'
[Feb 23 02:29:02] VERBOSE[13700][C-00000015] pbx.c:     -- Executing [s@inmobilesms:4] MessageSend("Message/ast_msg_queue", "SIP:2204, "10658487" <10658487>") in new stack
[Feb 23 02:29:02] DEBUG[13700][C-00000015] chan_sip.c: Allocating new SIP dialog for 0fbab17f578da9ee682c647a5757b32e@(null) - MESSAGE (No RTP)
{noformat}

Looks to me like this part of your dialplan is not working properly:

{noformat}
[inmobilesms]
exten => s,1,NoOp(Incoming SMS from ${MESSAGE(from)} : ${MESSAGE(body)})
exten => s,n,Set(ACTUALFROM=${CUT(MESSAGE(from),@,1)})
exten => s,n,Set(ACTUALFROM=${CUT(ACTUALFROM,:,2)})
exten => s,n,MessageSend(SIP:2204, "${ACTUALFROM}" <${ACTUALFROM}>)
exten => s,n,Hangup()
{noformat}

ACTUALFROM does not have a proper host address and therefore the host address is set to (null) which is correct since there is no host address that could be set.

By: Michael L. Young (elguero) 2013-02-22 16:08:15.396-0600

I am going to go ahead and close this as not a bug.  After fixing your configuration, if you feel there is still a bug, don't hesitate to contact a bug marshal in order to re-open this issue.
By: Zhi Cheng (chengzhicn) 2013-02-22 23:06:32.721-0600

I changed my dialplan, but 'via' header is still '(null)'.
Here is new dialplan:
{noformat}
[inmobilesms]
exten => s,1,NoOp(Incoming SMS from ${MESSAGE(from)} : ${MESSAGE(body)})
exten => s,n,MessageSend(SIP:2204@192.168.0.83)
exten => s,n,Hangup()
{noformat}
By: Zhi Cheng (chengzhicn) 2013-02-22 23:07:28.822-0600

Here is tcpdump result and debug log using new dialplan
By: Zhi Cheng (chengzhicn) 2013-02-26 01:30:06.828-0600

After days of digging source code, I found out that sip_msg_send did not poper update 'via' header after 'ast_sip_ouraddrfor', thus the 'via' header in the SIP MESSAGE is initialized in 'sip_alloc' from 'internip'.
In my case, the hostname of my router is not resolvable, so resulting null 'internip' and null 'via' header.
By: Zhi Cheng (chengzhicn) 2013-02-26 01:31:29.083-0600

patch attached
By: Jonathan Rose (jrose) 2013-02-28 15:03:54.273-0600

One thing worth noting is that I really don't think we should allow the update_via function write anything in the event that the ourip value is NULL. That's just asking for trouble.  That said, chan_sip is a fickle beast and the patch provided is relatively harmless (and really we should be changing the via field if we update ourip) while changing the way build_via works seems like it could have a much more widespread effect, so I'm going to go ahead and run with it.



EDIT:  @Zhi Cheng so when I tried to check on your patch license number I noticed that it wasn't marked as a contribution and on attempting to do so JIRA just silently rejected marking it as a contribution.  Have you signed a license agreement? I need you to have a license agreement in order to legally be allowed to commit your code.
By: Michael L. Young (elguero) 2013-02-28 21:17:47.684-0600

Jonathan, there might be a couple other functions that are missing the call to build_via after calling ast_sip_ouraddrfor... I found sip_cc_monitor_request_cc and transmit_publish calling sip_alloc without an addr set and therefore, would possibly suffer from the same issue without a call to build_via to update the Via header.
By: Zhi Cheng (chengzhicn) 2013-03-03 21:44:02.099-0600

@Jonathan Rose I signed the License Agreement, but it seems it's still pending.
@Michael L. Young Both sip_cc_monitor_request_cc and transmit_publish call down to build_via through transmit_invite.
By: Jonathan Rose (jrose) 2013-03-07 13:47:57.145-0600

Zhi: Thanks. It's working now. I'll commit the patch before the end of the day probably.