*NUMBER,HOSTNAME and PASSWORD are aliases of actual values.
As you can see “Authorization” field with login digests is missing, even though “username” and “secret” are there in configuration file.
I’d like to debug it, but I don’t know where to start…any idea?
Hi,
Are you using any softphone or IP phone or any simulator. We have tested this scenario in our site and it works fine. The client should support MD5 algorithm and openSSL etc to send Authorization header in response to 401 Unauthorized from Asterisk
Hi, actually it’s an Asterisk PBX on a dedicated HP Proliant micro-server, trying to register the VoIP trunk.
Inspired by your comment I checked for “Authorization requirements”: OpenSSL is installed and MD5 is available as well. Also tested same parameters on another machine and they work, so cannot be server-side problem.
So the machine has something wrong, I say I would debug it, but I don’t know where to start…
Is it like an endpoint behind Asterisk trying to register to or via a server Cirpack. Could you send a network level architecture diagram and traces on asterisk. Have you configured the SIP trunk as per asterisk’s format. please check. when you are saying it is working in another set up , do you mean asterisk in other set up is able to register the trunk with the server(peer)
Actually here we are talking about a very basic network environment: Asterisk PBX machine itself is trying to register a remote VoIP public trunk on our provider registrar server, through Internet. So basically there are PBX – router – WAN – router – Registrar.
The other machine I used for testing is architecturally the same as for either software and hardware, just on a totally different geographic location and WAN, and it is able to register the same trunk by same parameters.
Asked provider about this and came out that our Asterisk PBX is trying to register to their server but is not providing any “Authorization” digest, therefore Registrar keep rejecting it because of lack of authentication. Thus this topic.
I hope to have put some light on the situation answering your polite questions.
The remote system is broken. Call-IDs are opaque strings, but it has rewritten an IPV6 address in the call-id with an alternative form of the same address.
Unless there is some special exception for IPV6 address literals, that is not allowed.
The Call-ID header field acts as a unique identifier to group
together a series of messages. It MUST be the same for all requests
and responses sent by either UA in a dialog. It SHOULD be the same
in each registration from a UA.[color=#FF0000]simply compared byte-by-byte[/color].
[/quote]
[quote]20.8 Call-ID
The Call-ID header field uniquely identifies a particular invitation
or all registrations of a particular client. A single multimedia
conference can give rise to several calls with different Call-IDs,
for example, if a user invites a single individual several times to
the same (long-running) conference. Call-IDs are case-sensitive and
are [color=#FF0000]simply compared byte-by-byte.[/color][/quote]
The two strings you quote are not byte for byte identical, so they are not the same call-id.
The part after the ‘@’ has no meaning beyond being part of the call-id. It is not an IPV6, or any other address literal, so it is not subject to IPV6 address literal equivalences.
The target UAS is broken.
(RFC 6157 makes no mention of call-id, which tends to support the assumption that the base RFC is not overridden for IPv6.)
Good shot david55! That’s a very relevant suggestion.
I am in test with provider already.
That would explain all the timeouts on registration too.
I will let you know the updates.
david55 the more days pass the more you are right.
ISP now is telling me to put IPv4-style host part in Call-ID because their server is not IPv6 certified so it translates mistakenly the Call-ID.
In order to try this way, could I at this point set in any way that host part as IPv4? Even just for testing.