On 21.10.10 15:56, Tobias Lindgren wrote:
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?
yep! I asked some colleagues who confirmed that as well ;-)
RFC 3261, section 8.1.2 (Sending the Request) describes that we should
use the procedures in RFC3263. As far as I know, it does not say
anywhere that we should save anything from the previous request...
Section 4 in RFC3263 is more precise:
"The procedures here MUST be done exactly once per transaction, where
transaction is as defined in [1]. That is, once a SIP server has
successfully been contacted (success is defined below), all
retransmissions of the SIP request and the ACK for non-2xx SIP
responses to INVITE MUST be sent to the same host. Furthermore, a
CANCEL for a particular SIP request MUST be sent to the same SIP
server that the SIP request was delivered to.
"
The second INVITE with authentication headers is a case similar to the
2xx-ACK: it represents a new transaction.
-Raphael.
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
