Hi Tony,

The listener caught the exception.  The exception was thrown by
** at gov.nist.javax.sip.clientauthutils.AuthenticationHelperImpl.handleChallenge(AuthenticationHelperImpl.java:237) which clearly is related to the 407 response. I don't think this has anything to do with transport.

There is no error in the proxy. It is stuck in that state. Would you be able to replicate a call via siptrunk where the BYE is initiated from the internal extension? I need to see if in current implementation, the proxy tries to authenticate the bridge for mid dialog requests. If it does, then i need to dig deeper into the bridge code. If it doesn't, then i'll dig into the proxy code. I just need the correct target to start shooting at it.

Joegen

On Monday, 20 September, 2010 06:12 PM, Tony Graziano wrote:
Does the proxy log show anything? The first thing the error message indicates is a listening issue.

On Mon, Sep 20, 2010 at 5:56 AM, Joegen Baclor <[email protected] <mailto:[email protected]>> wrote:

    Hi Tony,

    Indeed the bridge is still listening using it's old 5080 WAN
    port.  If you scrutinize the BYE, however, you will notice that it
    has a Route: header which points to the proxy via 5060

    BYE sip:[email protected]:5080 SIP/2.0
    Via: SIP/2.0/UDP 192.168.1.10;rport;branch=z9hG4bKrxbjobeu
    Route: <sip:192.168.1.11:5060;lr;x-sipX-done>
    Max-Forwards: 70
    To: <sip:[email protected]>;tag=585002639
    From: "Joegen Baclor" <sip:[email protected]>;tag=efacf
    Call-ID: jylknqgyhblq...@bravia-c4
    CSeq: 731 BYE
    User-Agent: Twinkle/1.4.2
    Content-Length: 0



    On Monday, 20 September, 2010 05:49 PM, Tony Graziano wrote:
    Looking at the sipxbridge log, I see the by from 201, then the
    errors start. I think the question is where the bye should be
    sent and ack'd. Without seeing the sipxproxy.log its kind of hard
    to say. The error implies a listening error, but that is a bit of
    a long message and can simply be a result of "not knowing" what
    to do... the twinkle log looks plain, it shows sending the bye to
    bridge on port 5080. Is sipxbridge still listening locally on
    port 5080 in this environment?I just don;t know how to read it
    because the sipxbridge log shows the BYE on port 5060 and the
    twinkle log shows 5080.

    nBYE sip:[email protected]
    <mailto:sip%[email protected]>;x-sipX-nonat SIP/2.0\r\nVia:
    SIP/2.0/UDP 112.201.137.176:5080 <http://112.201.137.176:5080>;

    Can you explain how the call flow for a bye should work (which
    service/port) and where it should be sent (directly to sipxbridge
    is my guess from the client and vice versa)?
    On Mon, Sep 20, 2010 at 2:19 AM, Joegen Baclor <[email protected]
    <mailto:[email protected]>> wrote:

        Hi Folks,

        For those of you who are following the development on this
        thread, I have attached a new set of twinkle log that
        demonstrates a complete call that passes through 5060 coming
        from a dummy ITSP.  The previous log I have sent contained a
        glitch that is now corrected.  I needed to modify contact
        creation in sipXbridge a bit so that it sends the internal IP
        address when talking to the proxy.   This glitch is now
        corrected.

        However, I am now facing a new issue.  When the BYE is coming
        from the called extension, sipXproxy sends a 407 for the BYE
        and sipXbridge suddenly barfs an exception

        
"2010-09-20T05:48:59.328000Z":1188:sipxbridge:ERR:c2.ossapp.com:Thread-88:00000000:SipListenerImpl:"Unexpected
        error processing response >>>> SIP/2.0 407 Proxy
        Authentication Required\r\nFrom:
        <sip:[email protected]>;tag=784036913\r\nTo: \"Joegen
        Baclor\" <sip:[email protected]>;tag=bjome\r\nCall-ID:
        kteensdeyxos...@bravia-c4\r\ncseq: 1 BYE\r\nVia: SIP/2.0/UDP
        
112.201.137.176:5080;branch=z9hG4bK5fe25839220b0a96ff883192d4d6e60a373835;received=192.168.1.11;rport=5080\r\nProxy-Authenticate:
        Digest realm=\"c2.ossapp.com
        
<http://c2.ossapp.com>\",nonce=\"e669226f7847e446773d4cceeddd161a4c96f5cb\",qop=\"auth\"\r\nServer:
        sipXecs/4.3.0 sipXecs/sipXproxy (Linux)\r\nDate: Mon, 20 Sep
        2010 05:48:59 GMT\r\nContent-Length: 0\r\n\r\n"
        javax.sip.SipException: Unexpected exception

        Newbie Questions:
        1.  Is the proxy suppose to authenticate mid-dialog requests
        from the bridge?  Is this how it behaves currently?
        2.  What could be causing the bridge to barf?  Isn't it
        suppose to just relay the response to the callee since it
        would know how to construct the authentication?  Or is this
        something I have introduced by messing around with contact?

        Joegen



        On Thursday, 16 September, 2010 11:51 PM, Tony Graziano wrote:
        I feel a little left out because they won't approve my
        openscs registration request.

        On Thu, Sep 16, 2010 at 11:35 AM, Matt White
        <[email protected] <mailto:[email protected]>>
        wrote:

            Sweet!....thats what I was hoping to hear.

            I didn't think Avaya has released any code for it's new
            openscs project as the website still has nothing new
            from June.  But was wondering if I missed something if
            Avaya had actually released openscs code.

            I do think its funny the openscs webpage notes that
            "/*As of July Avaya no longer participates in
            SIPFoundry. SIPFoundry has forked the code base and is
            being maintained by a new startup company.*/"

            Rather than Avaya being the one that forked it into a
            new openscs project ;-)

            -M

            >>> Joegen Baclor 09/16/10 10:00 AM >>>

            Hi Matt,

I've heard that Avaya is trying to solve this as well. But this one is completely community/ezuce code.

            Joegen

            On Thursday, 16 September, 2010 09:04 PM, Matt White wrote:
            Great news.  This will go a long way towards increased
            interop.

            Out of curiosity, is any of this based on the work that
            avaya was doing before the fork?  Or is this 100%
            community/ezuce code?

            -M

            >>> Joegen Baclor <[email protected]>
            <mailto:[email protected]> 09/16/10 4:37 AM >>>
            Hi Folks,

            I just thought you'd be interested in knowing that I
            have already
            successfully sent a call to port 5060 and forwarded to
            the bridge by
            redirection. See attached log from twinkle.
            Unfortutely, I am behind
            a firewall controlled by the ITSP so this is not yet
            tested in an actual
            environment. If you take a look at the log I have
            attached, the 200 OK
            is now coming from sipXbridge event if the call passed
            through the main
            sipXproxy listener. The ACK in this case will be
            misrouted because
            sipXbridge is sending the external IP as its contact.
            This however
            should not be an issue if the actual test call came
            from an entity
            outside my firewall. Hopefully we will have some more
            good news in the
            days to come.

            Joegen


            _______________________________________________
            sipx-dev mailing list
            [email protected]  <mailto:[email protected]>
            List Archive:http://list.sipfoundry.org/archive/sipx-dev/


            _______________________________________________
            sipx-dev mailing list
            [email protected]
            <mailto:[email protected]>
            List Archive: http://list.sipfoundry.org/archive/sipx-dev/




-- ======================
        Tony Graziano, Manager
        Telephone: 434.984.8430
        sip: [email protected]
        <mailto:[email protected]>
        Fax: 434.984.8431

        Email: [email protected]
        <mailto:[email protected]>

        LAN/Telephony/Security and Control Systems Helpdesk:
        Telephone: 434.984.8426
        sip: [email protected]
        <mailto:[email protected]>
        Fax: 434.984.8427

        Helpdesk Contract Customers:
        http://www.myitdepartment.net/gethelp/

        Why do mathematicians always confuse Halloween and Christmas?
        Because 31 Oct = 25 Dec.


        _______________________________________________
        sipx-dev mailing list
        [email protected]  <mailto:[email protected]>
        List Archive:http://list.sipfoundry.org/archive/sipx-dev/




-- ======================
    Tony Graziano, Manager
    Telephone: 434.984.8430
    sip: [email protected]
    <mailto:[email protected]>
    Fax: 434.984.8431

    Email: [email protected]
    <mailto:[email protected]>

    LAN/Telephony/Security and Control Systems Helpdesk:
    Telephone: 434.984.8426
    sip: [email protected]
    <mailto:[email protected]>
    Fax: 434.984.8427

    Helpdesk Contract Customers:
    http://www.myitdepartment.net/gethelp/

    Why do mathematicians always confuse Halloween and Christmas?
    Because 31 Oct = 25 Dec.





--
======================
Tony Graziano, Manager
Telephone: 434.984.8430
sip: [email protected] <mailto:[email protected]>
Fax: 434.984.8431

Email: [email protected] <mailto:[email protected]>

LAN/Telephony/Security and Control Systems Helpdesk:
Telephone: 434.984.8426
sip: [email protected] <mailto:[email protected]>
Fax: 434.984.8427

Helpdesk Contract Customers:
http://www.myitdepartment.net/gethelp/

Why do mathematicians always confuse Halloween and Christmas?
Because 31 Oct = 25 Dec.


_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev/

Reply via email to