If you send FS an INVITE with an authorization, it will try to process
the authorization as if it were the one who sent the challenge. In this
case, it was sipx which first challenged the INVITE. Being a proxy,
sipx does not remove the authorization header prior to sending it to
freeswitch and this is the desired behavior and can never change. My
advise is to create a dummy user and have the user be redirected to
freeswitch. This way freeswitch gets a fresh invite everytime.
On Saturday, 25 December, 2010 04:44 PM, Nikolay Kondratyev wrote:
Hi all,
i got no reply in the users list.
I'm forwarding my problem here.
I hope somebody can clarify my problem...
Thanks in advance,
Nikolay.
------------------------------------------------------------------------
*From:* [email protected]
[mailto:[email protected]] *On Behalf Of
*Nikolay Kondratyev
*Sent:* Wednesday, December 22, 2010 7:03 PM
*To:* 'Discussion list for users of sipXecs software'
*Subject:* [sipx-users] duplicated challenge
Hi all,
i encountered "duplicated challenge" from sipx.
I have a separate FS profile on the same machine as sipx,
listening on 15080, which works as sip-h.323 gw between sipx and
avaya ipoffice.
I also have an ITSP (sipnet) connection through sipxbridge.
When i call ipoffice -> sip-h.323 gw -> sipx -> sipnet without
"proxy authentication" (no permission required in corresponding
dial rule), all is going well.
Ok, then i configured a fake user in the sipx. And made my
sip-h.323 gw to use this user's credentials for proxy authentication.
And i checked, say longdistance, permission required in the
corresponding dial rule.
I see that my sip-h.323 gw (FS) re-sends invite with
proxy-authorization header.
But then ... Invite gets challenged the second time.... Please see
attached trace.
The whole snapshot is available at
ftp://sipx:[email protected]/dup-challenge-sipx-configuration-beaver.sip.nstel.ru.tar.gz.
And FS, i guess, does not know what to do with it...
Can anybody please advise why this "duplicated challenge" happens
and what can be done about that?
Is there something wrong in the signalling?
Thanks in advance,
Nikolay.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/
