| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
Oh dear, For the second registration, I still had: SharedPtr<SipMessage>
regMessage = pClientDum->makeRegistration(pLineProfile->getDefaultFrom()); If I change this to: SharedPtr<SipMessage>
regMessage = pClientDum->makeRegistration(pLineProfile->getDefaultFrom(),
pLineProfile); All is well with the world. Sorry. From: SCG2 [mailto:sgregor1@xxxxxxxxxxxxx]
Sorry, more info - REGISTER for 01288271237 (totally different CallID from the
initial register for “zb-simon”) is challenged by Sip server: DEBUG | 20090109-110206.562 | RESIP:TRANSACTION | 3512 |
TransactionState.cxx:1956 | Send to TU: TU: DialogUsageManager size=0 SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.100:11329;rport;branch=z9hG4bK-d8754z-4256ed2a8a42186b-1---d8754z- To: <sip:01288271237@xxxxxxxxxxx:5060> From: <sip:01288271237@xxxxxxxxxxx:5060>;tag=013c686a Call-ID: NTJlNmU4NzU0ZjZmNDI5YWY1NmY3MmQ1OGEyN2UyZTA. CSeq: 1 REGISTER WWW-Authenticate: Digest
nonce="1231674633",realm="192.168.1.8" Content-Length: 0 DEBUG | 20090109-110206.562 | RESIP:TRANSACTION | 3512 |
TimerQueue.cxx:85 | Adding timer: Timer K tid=4256ed2a8a42186b ms=5000 INFO | 20090109-110206.562 | RESIP:DUM | 3512 | DialogUsageManager.cxx:1299
| Got: SipResp: 401 tid=4256ed2a8a42186b cseq=REGISTER / 1 from(wire) STACK | 20090109-110206.562 | RESIP:DUM | 3512 |
DialogUsageManager.cxx:1923 | Looking for dialogSet:
NTJlNmU4NzU0ZjZmNDI5YWY1NmY3MmQ1OGEyN2UyZTA.-013c686a in map: STACK | 20090109-110206.562 | RESIP:DUM | 3512 |
DialogUsageManager.cxx:1924 |
[NTJlNmU4NzU0ZjZmNDI5YWY1NmY3MmQ1OGEyN2UyZTA.-013c686a -> 064ACD70,
OWI0MDcwMDU3MDhjYjRlNjc0MzE5OGMyZTE2NDY1YzM.-741b3860 -> 064A5D18,
Y2U5M2QxMzdjOTIwNTAwODI2OWNlZWE0YjJjZTQ2Mjc.-305fe57d -> 06499248,
ZDhiZDJmOTY1ZjcxMmY3YmNlNWEzMjQ2ZjJhMWY3YmE.-861dca47 -> 064A9650] DEBUG | 20090109-110206.562 | RESIP:DUM | 3512 |
DialogUsageManager.cxx:1807 | DialogUsageManager::processResponse: SipResp: 401 tid=4256ed2a8a42186b cseq=REGISTER / 1 from(wire) DEBUG | 20090109-110206.562 | RESIP:DUM | 3512 |
ClientAuthManager.cxx:224 | ClientAuthManager::RealmState::handleAuth: 064B9578
Digest nonce="1231674633",realm="192.168.1.8" is proxy: 0 DEBUG | 20090109-110206.562 | RESIP:DUM | 3512 | ClientAuthManager.cxx:198
| ClientAuthManager::RealmState::transition from invalid to current DEBUG | 20090109-110206.562 | RESIP:DUM | 3512 |
UserProfile.cxx:158 | Found credential for realm: realm=192.168.1.8
user=zb-simon192.168.1.8 The last logging line it seems to have decided that the cred it
wants is for zb-simon, which was only passed in first REGISTER. As I say the
realms for both REGISTERs are the same. Hope this helps. From: SCG2
[mailto:sgregor1@xxxxxxxxxxxxx] Hi, I am having kittens over this one. · Set up
a master profile with a defaultFrom of FREDDY, realm etc · Send a
REGISTER (1) which is challenged and Resip generates a REGISTER (2) with an
Authorixation header with a username=”FREDDY”……great (I
setDigestCredential(,“FREDDY”,) etc) So all good to here, then: · Set up
a user profile
with SharedPtr<UserProfile>
pLineProfile = SharedPtr<UserProfile>(new UserProfile()); and a defaultFrom of “BILLY”, same realm as FREDDY · Send a
REGISTER (3) for BILLY which looks correct, and is challenged… · ….Resip
sends a REGISTER (4) with a correct From: / To: etc (BILLY) but the response to
the challenge contains the original FREDDY from the master profile digest
creds, even though REGISTER (3) clearly used the contents of pLineProfile i.e.
it created From: BILLY I have tried clearing the digest credentials from pLineProfile
before adding SetDigestCredentials(,“BILLY”,) prior to sending
REGISTER (3). This was in case pLineProfile was somehow inheriting the base
profile, ending up with 2 x creds (with the same realm) and serving up the
master one when being challenged. Any pointers gratefully received. |