Hi Martin,
That is the ultimate goal. That would require modifying the behavior of
sipXbridge to have the proxy as a static route-set. I suspect this to
be a trivial work on sipXbridge. However Java is not my realm so what
might be a trivial job could take me a bit longer. I would appreciate
any help from the community on this. For now, the goal of my testing is
to just prove that a static redirector is possible to force stray
messages towards 5060 bound to 5080 gets there.
Joegen
On Wednesday, 22 September, 2010 08:58 AM, Martin Steinmann wrote:
Joegen
Nice work. After this patch is applied, is port 5080 still involved
in any way? I thought all signaling would then be transacted over
port 5060 both to internal phones, remote workers and ITSPs. Probably
I am missing something, because if this was the case then why are you
interested in the test case below?
--martin
*From:* [email protected]
[mailto:[email protected]] *On Behalf Of *Joegen Baclor
*Sent:* Tuesday, September 21, 2010 6:25 PM
*To:* sipXecs developer discussions
*Subject:* Re: [sipx-dev] 5060/5080 trunking issues almost solved
pending actualtests
Hi Everyone,
I had a chance to test this patch using an ITSP. I used voip.ms to
test. The call worked with bidirectional audio and I was satisfied.
The logs however shows that voip.ms did not send the call to port 5060
but via the registration port 5080. Can you point me to an ITSP that
insists on sending to 5060? Or better yet, if you have an account
with an ITSP that behaves this way, would you be able to throw my test
server an inbound call via sip-trunk reg? Any help would be
appreciated. Thanks.
Joegen
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.
_______________________________________________
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/
