Re: Failure to receive ACK with Ekiga
Felix Lechner <[email protected]> Sun, 5 Dec 2010 02:30:53 -0800
| Newsgroups | gmane.network.siproxd |
|---|---|
| Message-ID | <[email protected]> |
--===============2703890991573825769== Content-Type: multipart/alternative; boundary=0022152d69595cfb2a0496a745f2 --0022152d69595cfb2a0496a745f2 Content-Type: text/plain; charset=UTF-8 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 <[email protected]> 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 <[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%3A7476686228-czJE/[email protected] <sip%253A7476686228-czJE/[email protected]>> -> > sip:17476686228-/[email protected] <sip%3A17476686228-/[email protected]> > > <sip%3A17476686228-/[email protected] <sip%253A17476686228-/[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%3A7476686228-czJE/[email protected] <sip%253A7476686228-czJE/[email protected]>> -> > > sip:17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org<sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org> > <sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org<sip%253A17476686228-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%3A7476686228-/[email protected] <sip%253A7476686228-/[email protected]>> -> > sip:17476686228-/[email protected] <sip%3A17476686228-/[email protected]> > > <sip%3A17476686228-/[email protected] <sip%253A17476686228-/[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%3A7476686228-/[email protected] <sip%253A7476686228-/[email protected]>> -> > > sip:17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org<sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org> > <sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org<sip%253A17476686228-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 > >> > >> > > > ------------------------------------------------------------------------------ > 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 > [email protected] > https://lists.sourceforge.net/lists/listinfo/siproxd-users > > --0022152d69595cfb2a0496a745f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable My suggestion would be to handle this the way my old Sony Ericsson mobile m= atched caller IDs to numbers in the address book. =C2=A0It resembled the is= sue at hand.<div><br></div><div>On mobile phones, incoming caller IDs can s= how up with various international access codes=C2=A0(for example, for a=C2= =A0<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"= >call from Germany while in the US, +49, 01149 and 0049). =C2=A0The goal is= to match the caller ID to an entry in the address book so the caller's= name can be displayed.<div> <br></div><div>My old phone compared caller IDs by matching digits digits b= ackwards from the end. =C2=A0It 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).</div> <div><br></div><div>Another, completely different way would be to forward t= he ACK to all active sessions. =C2=A0The clients then could decide if the U= RL matches their session, and respond as required by the standard.</div><di= v> =C2=A0</div><div><br><div class=3D"gmail_quote">On Sun, Dec 5, 2010 at 1:41= AM, Thomas Ries <span dir=3D"ltr"><<a href=3D"mailto:[email protected]">tri= [email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I might think of something that would allow siproxd to deal with such<br> providers.<br> <div><div></div><div class=3D"h5"><br> On =C2=A01 Dec, Felix Lechner wrote:<br> > It is a problem with the username. =C2=A0Looks like Sipphone/Gizmo5/Go= ogle<br> > does not send the initial '1' back in the ACK, even though it = is<br> > required for SIP registration. =C2=A0Siproxd correctly complains that = the<br> > UA is not registered.<br> ><br> > The ACK is not forwarded to the client. =C2=A0Ekiga drops the call aft= er a<br> > timeout.<br> ><br> > To solve, I changed the function 'compare_url()' in file '= sip_utils.c'<br> > from<br> ><br> > =C2=A0 =C2=A0 =C2=A0 if (strcmp(url1->username, url2->username) = !=3D 0) {<br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEBUGC(DBCLASS_PROXY, "compare_= url: username mismatch");<br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return STS_FAILURE;<br> > =C2=A0 =C2=A0 =C2=A0 }<br> ><br> > to<br> ><br> > =C2=A0 =C2=A0 =C2=A0 if (strcmp(url1->username, url2->username) = !=3D 0<br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 && strncmp(url2->username, &quo= t;1", 1) =3D=3D 0<br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 && strcmp(url1->username, url2-= >username + 1) !=3D 0) {<br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DEBUGC(DBCLASS_PROXY, "compare_= url: username mismatch");<br> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return STS_FAILURE;<br> > =C2=A0 =C2=A0 =C2=A0 }<br> ><br> > It probably isn't the best way to deal with this Sipphone/Google V= oice<br> > quirk, but it works for me. =C2=A0The ACK is now passed onto the Ekiga= <br> > client.<br> > =C2=A0This is for incoming Gizmo5 calls that were originated on the Go= ogle<br> > Voice web interface or a browser plugin.<br> ><br> > Just made two calls that were longer than thirty seconds. =C2=A0Previo= usly,<br> > Ekiga dropped the call after approximately 32 seconds.<br> ><br> ><br> > ---------- Forwarded message ----------<br> > From: Felix Lechner <<a href=3D"mailto:[email protected]">fel= [email protected]</a>><br> > Date: Tue, Nov 30, 2010 at 5:47 PM<br> > Subject: Re: [Siproxd-users] Failure to receive ACK with Ekiga<br> > To: Siproxd-users <<a href=3D"mailto:[email protected]= e.net">[email protected]</a>><br> ><br> ><br> > Hello Thomas,<br> ><br> > The excerpt below is from the debug log.<br> ><br> > Server is Sipphone. =C2=A0Client is Ekiga. =C2=A0Network is complex. = =C2=A0Nested NAT.<br> ><br> > Is it possible the user name mismatch has anything to do with it?<br> ><br> > Thank you,<br> > Felix<br> ><br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: siproxd.c:526<br> > received SIP type REQ:ACK<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349<br> > fetching outbound IP by HOSTNAME<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:89<br> > proxy_request Nov 30 17:15:01 buffalo-linkstation siproxd[6237]:<br> > route_processing.c:63 route_preprocess: no Route header present<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS<br> > lookup - from cache: 192.168.11.177 -> 192.168.11.177<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1018<br= > > sip_find_direction: reghost:192.168.11.177 ip:198.65.166.131<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279<br> > comparing urls: <a href=3D"mailto:sip%3A7476686228-czJE/[email protected]">sip:7= 476686228-czJE/[email protected]</a><br> </div></div>> <<a href=3D"mailto:sip%253A7476686228-czJE/[email protected]">sip= %3A7476686228-czJE/[email protected]</a>> -> <a href=3D"mailto:sip%3A1747668622= [email protected]">sip:17476686228-/[email protected]</a><br> > <<a href=3D"mailto:sip%253A17476686228-/[email protected]">sip%3A1747668= 6228-/[email protected]</a>> Nov 30 17:15:01 buffalo-linkstation<br> <div class=3D"im">> siproxd[6237]: sip_utils.c:294 compare_url: username= mismatch<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279<br> > comparing urls: <a href=3D"mailto:sip%3A7476686228-czJE/[email protected]">sip:7= 476686228-czJE/[email protected]</a><br> </div>> <<a href=3D"mailto:sip%253A7476686228-czJE/[email protected]">sip%3A747= 6686228-czJE/[email protected]</a>> -><br> > <a href=3D"mailto:sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org">sip:17476686= 228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org</a><<a href=3D"mailto:sip%253A17476686228@proxy= 01.sipphone.com">sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org</a>><br> <div class=3D"im">> Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: s= ip_utils.c:294<br> > compare_url: username mismatch<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279<br> > comparing urls: <a href=3D"mailto:sip%3A7476686228-/[email protected]">sip:= 7476686228-/[email protected]</a><br> </div>> <<a href=3D"mailto:sip%253A7476686228-/[email protected]">sip%3A74= 76686228-/[email protected]</a>> -> <a href=3D"mailto:sip%3A17476686228@72= .254.95.107">sip:17476686228-/[email protected]</a><br> > <<a href=3D"mailto:sip%253A17476686228-/[email protected]">sip%3A1747668= 6228-/[email protected]</a>> Nov 30 17:15:01 buffalo-linkstation<br> <div class=3D"im">> siproxd[6237]: sip_utils.c:294 compare_url: username= mismatch<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:279<br> > comparing urls: <a href=3D"mailto:sip%3A7476686228-/[email protected]">sip:= 7476686228-/[email protected]</a><br> </div>> <<a href=3D"mailto:sip%253A7476686228-/[email protected]">sip%3A74= 76686228-/[email protected]</a>> -><br> > <a href=3D"mailto:sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org">sip:17476686= 228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org</a><<a href=3D"mailto:sip%253A17476686228@proxy= 01.sipphone.com">sip%3A17476686228-rne+wJe3e/u3Jhga2bR/9VaTQe2KTcn/@public.gmane.org</a>><br> <div><div></div><div class=3D"h5">> Nov 30 17:15:01 buffalo-linkstation = siproxd[6237]: sip_utils.c:294<br> > compare_url: username mismatch<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:382<br> > fetching interface IP by INTERFACE [1]<br> > =C2=A0Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:454 i= faddr<br> > lookup - from cache: eth0 -> 192.168.11.1 UP<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:349<br> > fetching outbound IP by HOSTNAME<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: utils.c:130 DNS<br> > lookup - from cache: 72.254.95.107 -> 72.254.95.107<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: sip_utils.c:1179<br= > > sip_find_direction: unable to determine direction of SIP packet<br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: plugin_logcall.c:12= 0<br> > INFO:ACK Call: +<a href=3D"mailto:16172295005-PWiYkomgkyVd7zL7/[email protected]">1617229500= [email protected]</a> -> <a href=3D"mailto:7476686228-czJE/[email protected]">7476686= 228-czJE/[email protected]</a><br> > Nov 30 17:15:01 buffalo-linkstation siproxd[6237]: proxy.c:242 request= <br> > [ACK] from/to unregistered UA (RQ: +<a href=3D"mailto:[email protected]= 18.1.144">16172295005-PWiYkomgkyVd7zL7/[email protected]</a> -><br> > <a href=3D"mailto:7476686228-/[email protected]">7476686228-/[email protected]</= a>)<br> ><br> ><br> ><br> > On Mon, Nov 29, 2010 at 10:08 AM, Thomas Ries <<a href=3D"mailto:tr= [email protected]">[email protected]</a>> wrote:<br> ><br> >> Can you provide a debug log of siproxd?<br> >> I'd like to see how the dropped ACK looks like. There is/was a= know<br> >> issue with <a href=3D"http://ekiga.net" target=3D"_blank">ekiga.ne= t</a>. In that articular case a wrong Content-Lenght<br> >> did cause the packet to be dropped by libosip2.<br> >> Are there any warnings/errors in the siproxd log file?<br> >><br> >> Regards,<br> >> /Thomas<br> >><br> >><br> </div></div><br>-----------------------------------------------------------= -------------------<br> What happens now with your Lotus Notes apps - do you make another costly<br= > upgrade, or settle for being marooned without product support? Time to move= <br> off Lotus Notes and onto the cloud with Force.com, apps are easier to build= ,<br> use, and manage than apps on traditional platforms. Sign up for the Lotus<b= r> Notes Migration Kit to learn more. <a href=3D"http://p.sf.net/sfu/salesforc= e-d2d" target=3D"_blank">http://p.sf.net/sfu/salesforce-d2d</a><br>________= _______________________________________<br> Siproxd-users mailing list<br> <a href=3D"mailto:[email protected]">Siproxd-users@lists.= sourceforge.net</a><br> <a href=3D"https://lists.sourceforge.net/lists/listinfo/siproxd-users" targ= et=3D"_blank">https://lists.sourceforge.net/lists/listinfo/siproxd-users</a= ><br> <br></blockquote></div><br></div></div> --0022152d69595cfb2a0496a745f2-- --===============2703890991573825769== 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 --===============2703890991573825769== 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 --===============2703890991573825769==--