Hi Raphael! Ok, I understand. So if there are SRV-records used by a call, it should be ok by the "sip standard" to pick another ip-address even though it's an recurring/ongoing transaction? Br,/Tobias
> Date: Thu, 21 Oct 2010 13:06:06 +0200 > From: [email protected] > To: [email protected] > CC: [email protected]; [email protected] > Subject: Re: [Sems] Regarding SEMS and SRV records > > On 21.10.10 10:24, Tobias Lindgren wrote: > > 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 > A > > A > SEMS 100 Trying > > A > SEMS 407 Proxy Authentication Required > > SEMS ACK > A > > SEMS INVITE > B (with auth details) > > B > SEMS 100 Trying > > B > SEMS 407 Proxy Authentication Required > > SEMS 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? > > > > Exact. In my opinion, there is an issue with those Broadsoft switch. > What probably happens is following: proxy A generates a challenge which > cannot be authenticated by proxy B. If A and B are in the same SRV > record, it means that they should act the same. SR (sip-router) can deal > with this by sharing a secret and having their system clocks > synchronized (with NTP). > > > > Could I perhaps make it try the INVITE once more? > > > > At best, you should file a bug report to those people ;-) > > As a workaround, you could try to make the call stick to a server. This > should be possible by replacing the hostname in AmSipDialog::remote_uri > by the IP address of the server which generated the nonce (=> generated > the first reply). > For that purpose, we could add the source ip of the messages in the > AmSipReply/AmSipRequest classes. > > Cheers > Raphael. >
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
