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: Felix L. <fel...@gm...> - 2010-12-05 10:31:21
|
My suggestion would be to handle this the way my old Sony Ericsson mobile
matched caller IDs to numbers in the address book. It resembled the issue
at hand.
On mobile phones, incoming caller IDs can show up with various international
access codes (for example, for a call from Germany while in the US, +49,
01149 and 0049). The goal is to match the caller ID to an entry in the
address book so the caller's name can be displayed.
My old phone compared caller IDs by matching digits digits backwards from
the end. It matched across various international access codes and showed
the right name for the caller from the address book even when the access
codes did not match or were missing (our case).
Another, completely different way would be to forward the ACK to all active
sessions. The clients then could decide if the URL matches their session,
and respond as required by the standard.
On Sun, Dec 5, 2010 at 1:41 AM, Thomas Ries <tr...@gm...> wrote:
> 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%3A7476686228@74.125.66.80 <sip%253A7476686228@74.125.66.80>> ->
> sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107>
> > <sip%3A17476686228@72.254.95.107 <sip%253A17476686228@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%3A7476686228@74.125.66.80 <sip%253A7476686228@74.125.66.80>> ->
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@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%3A7476686228@72.254.95.107 <sip%253A7476686228@72.254.95.107>> ->
> sip:17476686228@72.254.95.107 <sip%3A17476686228@72.254.95.107>
> > <sip%3A17476686228@72.254.95.107 <sip%253A17476686228@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%3A7476686228@72.254.95.107 <sip%253A7476686228@72.254.95.107>> ->
> > sip:174...@pr...<sip%3A1...@pr...>
> <sip%3A1...@pr...<sip%253...@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
> >>
> >>
>
>
> ------------------------------------------------------------------------------
> 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
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
>
>
|
