< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index  

Re: [repro-users] [lumicall-users] "-1" after port in CANCEL message

Hi David,

I'm quite sure I saw a similar error with the ':-1' before I applied the IPv6 [ ] patch too, but at that time the error also said "bad port" referring to the ':-1', so I think these may be two separate issues occurring now.  One is that IPv4 is being wrapped in brackets [ ] and the other is that ':-1' is being appended to the CANCEL message anyway.  I'll try to get the logs you requested.

On 30 September 2015 at 06:51, David Holl <david+lumicallusers@xxxxxxxxx> wrote:
Hi Nabeel,

This looks related to a patch I recently submitted to wrap IPv6 addresses with [ ] so that v6 addresses (which use colons) don't get confused with the colon delimiting the port.

Would you be able to get a stack trace from Lumicall of when it first creates the Via header for that cancel message?

I suspect that some branch of code is calling BaseMessageFactory createRequest(...) with "" for the "via_addr" argument and -1 for the host_port.  So when my patch detects the : in the via_addr string, it assumes it is an IPv6 address and wraps the whole thing with [ ].  Thus when ViaHeader(proto, via_addr, host_port) gets invoked from createRequest, it appends the -1 from host_port.

So I'd like to figure out what code path causes the IPv4 address with the : port to be passed in as via_addr to createRequest.

If you're game for recompiling Lumicall, a stack trace can be dumped to adb logcat from ViaHeader without too much pain.  Try pasting these 2 lines into the bottom of the two ViaHeader(...) member functions in ViaHeader.java:

java.util.logging.Logger logger = java.util.logging.Logger.getLogger(getClass().getCanonicalName());
logger.info("ViaHeader diagnostic: host=" + host + " port=" + port + "\n" + android.util.Log.getStackTraceString(new RuntimeException("ViaHeader diagnostic")));

- David

On 9/29/15 10:04 PM, Nabeel wrote:
Just found out the problem part of the code which is causing this problem.  The following code in ViaHeader.java creates the unwanted "-1" in the CANCEL message, but I don't know how to fix it: 

/** Gets port of ViaHeader */
public int getPort() {
SipParser par = new SipParser(getSentBy());
if (par.hasMore())
return par.skipChar().getInt();
return -1;


On 30 September 2015 at 00:56, Nabeel <nabeelshikder@xxxxxxxxx> wrote:
I tested this in the latest version of Lumicall.  The problem seems to be caused by a strange ":-1" attached to end of the via address in the CANCEL message. 

Server log:

ERROR:core:parse_via:  <SIP/2.0/TLS []:-1;rport;branch=z9hG4bK25799^M
Max-Forwards: 70^M
To: <sip:test@xxxxxxxxxx;transport=tls>^M
From: <sip:test2@domain.com>;tag=z9hG4bK01018015^M
Call-ID: 903926898065@^M
Contact: <sip:test2@;transport=tls>^M
Expires: 3600^M
User-Agent: Lumicall/1.11.16/MP-S168^M
Content-Length: 0^M
Sep 30 00:43:51 server1 /usr/local/sbin/opensips[3285]: ERROR:core:parse_via: parsed so far:<SIP/2.0/TLS [10>
Sep 30 00:43:51 server1 /usr/local/sbin/opensips[3285]: ERROR:core:get_hdr_field: bad via
Sep 30 00:43:51 server1 /usr/local/sbin/opensips[3285]: INFO:core:parse_headers: bad header field
Sep 30 00:43:51 server1 /usr/local/sbin/opensips[3285]: ERROR:core:parse_msg: message=<CANCEL sip:test@xxxxxxxxxx;transport=tls SIP/2.0^M

ADB logcat: 

09-30 00:50:33.472  21767-21767/org.lumicall.android I/IntegratedSipProvider﹕ Sending message:
    CANCEL sip:test@xxxxxxxxxx;transport=tls SIP/2.0
    Via: SIP/2.0/TLS []:-1;rport;branch=z9hG4bK36227
    Max-Forwards: 70
    To: <sip:test@xxxxxxxxxx;transport=tls>
    From: <sip:test2@xxxxxxxxxx>;tag=z9hG4bK82667884
    Call-ID: 112920549595@
    CSeq: 2 CANCEL
    Contact: <sip:test2@;transport=tls>
    Expires: 3600
    User-Agent: Lumicall/1.11.16/MP-S168
    Content-Length: 0

lumicall-users mailing list