[Spce-user] Rewrite Rule for SIP Peering
Andrew Pogrebennyk
apogrebennyk at sipwise.com
Thu Jan 15 07:02:04 EST 2015
Hi,
SPCE does that if challenged by the remote peer with 401 or 407
response.. So my guess is that the peer rejects first INVITE and then
spce retries with empty username because it does not have peer_auth_*
settings configured, but I'm guessing because I didn't get the full
kamailio-proxy.log and kamailio-lb.log.
To configure this setting, open the Peering Server, then Remote
Authentication tab and edit the following three preferences:
peer_auth_user: <username for peer auth>
peer_auth_pass: <password for peer auth>
peer_auth_realm: <domain for peer auth>
The handbook will serve you well:
https://www.sipwise.com/doc/mr3.6.2/spce/ar01s06.html#_authenticating_and_registering_against_peering_servers
BR,
Andrew
On 01/15/2015 12:20 PM, Matthias Hohl wrote:
> Hello Andrew,
>
> i have solve the problem... it doesn't matter if the the forat is
> F=sip:0676 or not... the problem is at the asterisk SIP peering server of
> my sip carrier...
> The connection to the peer is without authentification but the SPCE send a
> empty Username so i get a username missmatch.
>
> This is the remote log message of the sip peering server, if i place a
> call from SPCE to this peering.
>
> Proxy-Authorization: Digest username="", realm="79.170.208.98",
> nonce="3365bf4f", uri="sip:436767788868 at 79.170.208.98:5060;transport=udp",
> response="708c52e4925f7816a5edd8ca3828dfbf", algorithm=MD5
>
> How can i deactivate that SPCE send even a username information to the
> peering..?
>
> BTW: Your rewrite rule you told me is just for Domains and not for peering
> or..?
More information about the Spce-user
mailing list