< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate] Proxy-Authorization realm


I assume you're using repro here? If so, it shouldn't be challenging BYE. In any case, repro decides what realm to use for the challenge based on the host found in the From header (provided it is a host it recognizes as being one of its own), and failing that, the Request-Uri. If the realm is changing on you, it is probably because the host in the From header is changing.

Best regards,
Byron Campen

Hi,

 

I just came across a potential problem in resiprocate (or in our application).

 

The AclStore is currently inactive, so resiprocate – acting as a UAS – is asking for authentication for each message. When the client sends an INVITE, resiprocate answers with a 407 with:

 

Proxy-Authorization: Digest username="24",realm="terastation5.m.terasens.de",nonce="12835812933:5145d934c594a99a742360f04560d34d",uri="sip:250@xxxxxxxxxxxxxxxxxxxxxxxxxx;user=phone",qop=auth,nc=00000001,cnonce="5b932ae2",response="e7c031b9

 

The client sends the correct Proxy-Authorization and the messages gets accepted.

When the client sends BYE later, resiprocate sends a 407 with:

 

Proxy-Authorization: Digest username="24",realm="192.168.20.12",nonce="12835812948:e969ac8d7671b4c2c0a282b0c022fd91",uri="sip:250@xxxxxxxxxxxxx:5060;user=phone",qop=auth,nc=00000001,cnonce="7f21c771",response="3b861f089995dd78b0aa6e597cfd2

 

The realm does not match anymore and the client cannot authenticate. Is this behaviour correct or shouldn’t resiprocate send the original realm value?

 

 

Thanks and best regards,

 

Matthias Moetje

<image001.jpg>

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

 

Phone:
Fax:
e-mail:
Web:

+49.89.143370-0
+49.89.143370-22
info@xxxxxxxxxxxx
www.terasens.com

 

 

<image001.jpg>
_______________________________________________
resiprocate-devel mailing list

Attachment: smime.p7s
Description: S/MIME cryptographic signature