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==--