Re: [Siproxd-users] Failure to receive ACK with Ekiga
Status: Beta
Brought to you by:
tries
Menu
▾
▴
Re: [Siproxd-users] Failure to receive ACK with Ekiga
|
From: Thomas R. <tr...@gm...> - 2010-12-05 09:41:55
|
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 <fel...@gm...>
> Date: Tue, Nov 30, 2010 at 5:47 PM
> Subject: Re: [Siproxd-users] Failure to receive ACK with Ekiga
> To: Siproxd-users <sip...@li...>
>
>
> 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@74.125.66.80
> <sip%3A7476686228@74.125.66.80> -> sip:17476686228@72.254.95.107
> <sip%3A17476686228@72.254.95.107> 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@74.125.66.80
> <sip%3A7476686228@74.125.66.80> ->
> sip:174...@pr...<sip%3A1...@pr...>
> 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@72.254.95.107
> <sip%3A7476686228@72.254.95.107> -> sip:17476686228@72.254.95.107
> <sip%3A17476686228@72.254.95.107> 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@72.254.95.107
> <sip%3A7476686228@72.254.95.107> ->
> sip:174...@pr...<sip%3A1...@pr...>
> 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@10.218.1.144 -> 7476686228@74.125.66.80
> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:242 request
> [ACK] from/to unregistered UA (RQ: +16172295005@10.218.1.144 ->
> 7476686228@72.254.95.107)
>
>
>
> On Mon, Nov 29, 2010 at 10:08 AM, Thomas Ries <tr...@gm...> 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
>>
>>
|
