Hi Stefan! Thank you for your prompt answer. It's an operator I use for outgoing calls, I think they are using a Broadsoft softswitch. My conclusions where a bit to quick, I'm not actually getting a 403 back directly on the reInvite. This is the correct flow:SEMS INVITE > AA > SEMS 100 TryingA > SEMS 407 Proxy Authentication RequiredSEMS ACK > ASEMS INVITE > B (with auth details)B > SEMS 100 TryingB > SEMS 407 Proxy Authentication RequiredSEMS ACK > B >From what I understand, it looks like SEMS thinks this is the same transaction >and would therefor not send another INVITE as it thinks the auth credentials >are incorrect? Could I perhaps make it try the INVITE once more? Br,/Tobias > Date: Wed, 20 Oct 2010 21:48:21 +0200 > From: [email protected] > To: [email protected] > CC: [email protected] > Subject: Re: [Sems] Regarding SEMS and SRV records > > Hi, > > Tobias Lindgren wrote: > > Hi all! > > > > I have a short question regarding how SEMS handles SRV-records. > > > > I'm using SEMS and the auth_b2b module, which mostly works just fine. > > However, by using a hostname that has SRV-records (it has no A-records > > what so ever), I'm having trouble to authenticate correctly with the > > other end and I'm not sure if this is due to SEMS handling SRV-records > > or if I'm doing something wrong. > > > > Let's say the hostname is "gw.sip.com" and behind that there are two > > SRV-records pointing to addresses A "192.168.10.1" and B "192.168.20.1" > > and they are load shared equally. > > > > My problem is that SEMS sends out the first INVITE to A, receives a 407, > > injects the auth response into the INVITE but now it sends the INVITE to > > B. B has no clue about this call/auth and therefore responds with a 403. > > > > Calls in this setup work fine 50% of the time because SEMS picks the > > correct SRV-record... =) Shouldn't SEMS remember and reuse the first > > address it talks to when resending the INVITE? > > > > Am I doing something wrong or is this by design? > > what kind of server is this that you are using? it seems to me your > server implementation of the auhentication is broken; the second > INVITE is sent as a completely new request, it could (should) actually > be a completely new dialog, and can very well be sent to the other > proxy. the other proxy can verify the password, too, as the nonce and > the response are in the request. > > what could be the reason is that the server somehow encodes some > information about itself in the nonce, in order to protect against DOS > attacks (it checks the checksum or some property of the nonce first, > before making the hash calculation on the password). but, this methods > should be choosen such that all the proxies recognize the nonces of > each other. > > are you sure that you get the 403 back if the other server is picked > the second time? it could actually also be that it fails becuase the > call-id and the from-tag should actually be changed (but i have never > seen a server remembering the request before authentication). > > Stefan > > > > > Best regards, > > /Tobias > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > Sems mailing list > > [email protected] > > http://lists.iptel.org/mailman/listinfo/sems > > > -- > Stefan Sayer > VoIP Services Consulting and Development > > Warschauer Str. 24 > 10243 Berlin > > tel:+491621366449 > sip:[email protected] > email/xmpp:[email protected] > >
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
