Re: Failure to receive ACK with Ekiga

--===============1961531201586047959==
Content-Type: MULTIPART/SIGNED; MICALG=pgp-sha1;
	PROTOCOL="application/pgp-signature";
	BOUNDARY="-1463810047-1714636915-1291542104=:18056"

---1463810047-1714636915-1291542104=:18056
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
Content-Disposition: INLINE

I might think of something that would allow siproxd to deal with such
providers.

On  1 Dec, Felix Lechner wrote:
> It is a problem with the username.  Looks like Sipphone/Gizmo5/Google
> does not send the initial '1' back in the ACK, even though it is
> required for SIP registration.  Siproxd correctly complains that the
> UA is not registered.
> 
> The ACK is not forwarded to the client.  Ekiga drops the call after a
> timeout.
> 
> To solve, I changed the function 'compare_url()' in file 'sip_utils.c'
> from
> 
>       if (strcmp(url1->username, url2->username) != 0) {
>          DEBUGC(DBCLASS_PROXY, "compare_url: username mismatch");
>          return STS_FAILURE;
>       }
> 
> to
> 
>       if (strcmp(url1->username, url2->username) != 0
>         && strncmp(url2->username, "1", 1) == 0
>         && strcmp(url1->username, url2->username + 1) != 0) {
>          DEBUGC(DBCLASS_PROXY, "compare_url: username mismatch");
>          return STS_FAILURE;
>       }
> 
> It probably isn't the best way to deal with this Sipphone/Google Voice
> quirk, but it works for me.  The ACK is now passed onto the Ekiga
> client.
>  This is for incoming Gizmo5 calls that were originated on the Google
> Voice web interface or a browser plugin.
> 
> Just made two calls that were longer than thirty seconds.  Previously,
> Ekiga dropped the call after approximately 32 seconds.
> 
> 
> ---------- Forwarded message ----------
> From: Felix Lechner <[email protected]>
> Date: Tue, Nov 30, 2010 at 5:47 PM
> Subject: Re: [Siproxd-users] Failure to receive ACK with Ekiga
> To: Siproxd-users <[email protected]>
> 
> 
> Hello Thomas,
> 
> The excerpt below is from the debug log.
> 
> Server is Sipphone.  Client is Ekiga.  Network is complex.  Nested NAT.
> 
> Is it possible the user name mismatch has anything to do with it?
> 
> Thank you,
> Felix
> 
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: siproxd.c:526
> received SIP type REQ:ACK
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349
> fetching outbound IP by HOSTNAME
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:89
> proxy_request Nov 30 17:15:01 buffalo-linkstation siproxd[6237]:
> route_processing.c:63 route_preprocess: no Route header present
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS
> lookup - from cache: 192.168.11.177 -> 192.168.11.177
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1018
> sip_find_direction: reghost:192.168.11.177 ip:198.65.166.131
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> comparing urls: sip:7476686228-czJE/[email protected]
> <sip%3A7476686228-czJE/[email protected]> -> sip:17476686228-/[email protected]
> <sip%3A17476686228-/[email protected]> Nov 30 17:15:01 buffalo-linkstation
> siproxd[6237]: sip_utils.c:294 compare_url: username mismatch
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> comparing urls: sip:7476686228-czJE/[email protected]
> <sip%3A7476686228-czJE/[email protected]> -> 
> sip:17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org<sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org>
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
> compare_url: username mismatch
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> comparing urls: sip:7476686228-/[email protected]
> <sip%3A7476686228-/[email protected]> -> sip:17476686228-/[email protected]
> <sip%3A17476686228-/[email protected]> Nov 30 17:15:01 buffalo-linkstation
> siproxd[6237]: sip_utils.c:294 compare_url: username mismatch
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279
> comparing urls: sip:7476686228-/[email protected]
> <sip%3A7476686228-/[email protected]> -> 
> sip:17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org<sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org>
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:294
> compare_url: username mismatch
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:382
> fetching interface IP by INTERFACE [1]
>  Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:454 ifaddr
> lookup - from cache: eth0 -> 192.168.11.1 UP
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349
> fetching outbound IP by HOSTNAME
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS
> lookup - from cache: 72.254.95.107 -> 72.254.95.107
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1179
> sip_find_direction: unable to determine direction of SIP packet
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: plugin_logcall.c:120
> INFO:ACK Call: +16172295005-PWiYkomgkyVd7zL7/[email protected] -> 7476686228-czJE/[email protected]
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:242 request
> [ACK] from/to unregistered UA (RQ: +16172295005-PWiYkomgkyVd7zL7/[email protected] ->
> 7476686228-/[email protected])
> 
> 
> 
> On Mon, Nov 29, 2010 at 10:08 AM, Thomas Ries <[email protected]> wrote:
> 
>> Can you provide a debug log of siproxd?
>> I'd like to see how the dropped ACK looks like. There is/was a know
>> issue with ekiga.net. In that articular case a wrong Content-Lenght
>> did cause the packet to be dropped by libosip2.
>> Are there any warnings/errors in the siproxd log file?
>>
>> Regards,
>> /Thomas
>>
>>

---1463810047-1714636915-1291542104=:18056
Content-Type: APPLICATION/PGP-SIGNATURE

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFM+15YB2xLpFxU+GURAkBAAJ9VMCD5ZxF6DzB4PoPQ8rwotG90RACePYtr
UgkCxQLKHG7OnK1IzeQ6rrE=
=ukdY
-----END PGP SIGNATURE-----

---1463810047-1714636915-1291542104=:18056--


--===============1961531201586047959==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

------------------------------------------------------------------------------
What happens now with your Lotus Notes apps - do you make another costly 
upgrade, or settle for being marooned without product support? Time to move
off Lotus Notes and onto the cloud with Force.com, apps are easier to build,
use, and manage than apps on traditional platforms. Sign up for the Lotus 
Notes Migration Kit to learn more. http://p.sf.net/sfu/salesforce-d2d
--===============1961531201586047959==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Siproxd-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/siproxd-users

--===============1961531201586047959==--