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
