Re: ERROR 483 too many hops
Thomas Ries <[email protected]> Tue, 14 Nov 2017 23:55:17 +0100
| Newsgroups | gmane.network.siproxd |
|---|---|
| Message-ID | <[email protected]> |
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============7562811492049822901== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="C6s9DsPaIjMGC7H23arPv2soIMhr2Vedv" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --C6s9DsPaIjMGC7H23arPv2soIMhr2Vedv Content-Type: multipart/mixed; boundary="kDOCsb5VUTS8UdXas2UFBhTuPsUC5flhj"; protected-headers="v1" From: Thomas Ries <[email protected]> To: [email protected] Cc: Kai Dupke <kdupke-IBi9RG/[email protected]> Message-ID: <5ff1fb37-337d-ece0-295d-d8a164bee8f3-hi6Y0CQ0nG0@public.gmane.org> Subject: Re: [Siproxd-users] ERROR 483 too many hops References: <f4134b0f-f348-1421-acc1-20c9141cde2f-IBi9RG/[email protected]> <8a9923f2-ea34-b2de-2cc0-54cba3002163-IBi9RG/[email protected]> <6524aa57-3a10-b7df-4035-dd61c8d9ee3d-IBi9RG/[email protected]> In-Reply-To: <6524aa57-3a10-b7df-4035-dd61c8d9ee3d-IBi9RG/[email protected]> --kDOCsb5VUTS8UdXas2UFBhTuPsUC5flhj Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hello Kai, The 483 is the result of siply exceeding the number of hops (Max-Forwards= ). Siproxd does not implement specific OPTIONS processing that covers this c= ase you observe. I will have to look into this. Would you be able to send me a trace (pcap or siproxd debug log fragment)= of such an OPTIONS message your PBX generates? Best regards, /Thomas On 11/14/2017 11:05 PM, Kai Dupke wrote: > On 11/14/2017 10:42 PM, Kai Dupke wrote: >> I looked into the dumps and what I get is >> >> TK.5062 > siproxd.5060: SIP: OPTIONS sip:kai@voip SIP/2.0 >> siproxd.5060 > TK.5062: SIP: SIP/2.0 483 Too Many Hops >> >> The dumps show the telephone system sends with "Max-Forwards:0" which = is >> rejected by siproxd for obvious reasons. >=20 > Never believe in something that looks obvious. >=20 > RFC3261: > The target of the OPTIONS request is identified by the Request-URI, > which could identify another UA or a SIP server. If the OPTIONS is > addressed to a proxy server, the Request-URI is set without a user > part, similar to the way a Request-URI is set for a REGISTER request= =2E >=20 > Alternatively, a server receiving an OPTIONS request with a *Max- > Forwards* header field value of 0 *MAY* respond to the request > regardless of the Request-URI. >=20 > So, it looks like the phone system tries to get some data from the > proxy, by setting max-forward to zero. >=20 > Not sure if the 'may' in the RFC could be answered by the 483 siproxd > sends or if this is a bug in siproxd handling of the OPTIONS message. >=20 > Does siproxd implements options handling at all (not forwarding an > options message, but answering a dedicated request via options message > to the proxy)? >=20 > However, this might explains why it still is working, as the answer is > optional, even I doubt optional is same as 483. >=20 > Best regards, > kai >=20 >=20 > -----------------------------------------------------------------------= ------- > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Siproxd-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/siproxd-users >=20 --kDOCsb5VUTS8UdXas2UFBhTuPsUC5flhj-- --C6s9DsPaIjMGC7H23arPv2soIMhr2Vedv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBCgAGBQJaC3RZAAoJEJ13f30qwnQAqOMQAIxtIEeWxWnqjBZg/v0+BZ5s zcyNDuf40B/Zt3gGZ1qisz4gNkd8Br9Ka63y5jYEk1OmjWCpcdriL9JQtrM0SjqA pJHYTF36y7Vz87kGVn6b32Uhot1ZrqwLArqSpeY/eur+IQ78WVXqQFJtkOdWJZZ8 epDJ3OJ/BxbXznook+ZVSmk/2gp/RLUbhXK3T0rFu3rC0g4OFAbhx1TvFc/IKvrg GPr7n8bafJYHbSXssN4YfMfToo6muOGi9aC47X9XIaNlR/DuKGbbyyVbztUvqsy3 GYxL7N22RAfnUHGrmojR6nuUukwRcJMG7hviP81SOGwA/piPRQPxq8BM5SgH2PGR +yJ2ENXKWSb4W7tix5aH9dGpp8NYqkK5jCGkoRUwrL7WK2zPOkxh2fPQ8l3mCUsY OwyY/kpd2JL66qMcKrn5fqe2wpXSR2MB8cGf8JKhcuuC6JUNRc2I81ysUSLqHCEE ulHgxN5sWOM3k8s+wx4h1xJt6yh9M2PcKoAY0nl0HjwoXow9x1PX/gXzFoV5PKi7 ewCQ5naQGGPxp9aXL1p02aJxtr1O2GrX6nDP5v2xy2IsBA9lupbiWKiEBlnn2Gdr 3syPgAge2NMAFhzYN7BK1UIEXg9Z7GSgYzrTWGIEnbI6HEyhjLNMYvbgD5qTXLzO +C4phgL+YgsBUTiGEgC9 =P1fV -----END PGP SIGNATURE----- --C6s9DsPaIjMGC7H23arPv2soIMhr2Vedv-- --===============7562811492049822901== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot --===============7562811492049822901== 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 --===============7562811492049822901==--