| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
I am not using repro, I have an application built on dum (registrar
& b2bua). Though, I found it now (has been a while since I did that): I was
simply using msg.header(h_RequestLine).uri().host() in MyServerAuthManager::getChallengeRealm instead for h_From. Thanks for your help, Matthias From: Byron Campen
[mailto:bcampen@xxxxxxxxxxxx] 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> _______________________________________________ resiprocate-devel mailing list | |||||||||