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

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


My current feeling on this IPv6 support stuff is that we need to

a) separate the code that originates from MjSIP

b) put it in a separate repository to build it is a standalone JAR

c) run it in the IDE, maybe with some unit tests, to flush out any more
IPv6 issues

d) use that JAR as part of Lumicall


I'll get the first two steps done shortly.



On 30/09/15 07:51, David Holl 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 "10.61.164.97:3434" 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());
>>     par.goToLast(':');
>>     if (par.hasMore())
>>     return par.skipChar().getInt();
>>     return -1;
>>     }
>>
>>
>>  
>>
>> On 30 September 2015 at 00:56, Nabeel <nabeelshikder@xxxxxxxxx
>> <mailto: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
>>         *[10.61.164.97:34341]:-1*;rport;branch=z9hG4bK25799^M
>>         Max-Forwards: 70^M
>>         To: <sip:test@xxxxxxxxxx
>>         <mailto:sip%3Atest@xxxxxxxxxx>;transport=tls>^M
>>         From: <sip:test2@xxxxxxxxxx>;tag=z9hG4bK01018015^M
>>         Call-ID: 903926898065@10.61.164.97
>>         <mailto:903926898065@10.61.164.97>^M
>>         CSeq: 2 CANCEL^M
>>         Contact: <sip:test2@10.61.164.97:34341;transport=tls>^M
>>         Expires: 3600^M
>>         User-Agent: Lumicall/1.11.16/MP-S168^M
>>         Content-Length: 0^M
>>         ^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
>>         <mailto:sip%3Atest@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
>>         <mailto:sip%3Atest@xxxxxxxxxx>sip:test@xxxxxxxxxx;transport=tls 
>> SIP/2.0
>>             Via: SIP/2.0/TLS
>>         *[10.61.164.97:34341]:-1*;rport;branch=z9hG4bK36227
>>             Max-Forwards: 70
>>             To:
>>         <<mailto:sip%3Atest@xxxxxxxxxx>sip:test@xxxxxxxxxx;transport=tls>
>>             From:
>>         
>> <<mailto:sip%3Atest2@xxxxxxxxxx>sip:test2@xxxxxxxxxx>;tag=z9hG4bK82667884
>>             Call-ID:
>>         <mailto:112920549595@10.61.164.97>112920549595@10.61.164.97
>>             CSeq: 2 CANCEL
>>             Contact: <sip:test2@10.61.164.97:34341;transport=tls>
>>             Expires: 3600
>>             User-Agent: Lumicall/1.11.16/MP-S168
>>             Content-Length: 0
>>
>>
>>
>>
>> _______________________________________________
>> lumicall-users mailing list
>> lumicall-users@xxxxxxxxxxxxxxxxxx
>> http://lists.lumicall.org/mailman/listinfo/lumicall-users
> 
> 
> 
> _______________________________________________
> lumicall-users mailing list
> lumicall-users@xxxxxxxxxxxxxxxxxx
> http://lists.lumicall.org/mailman/listinfo/lumicall-users
>