problem with simple proxy code

[Chris Lauwers]

Hi,

I seem to have a problem with simple proxying support. I'm using Twinkle as a SIP softphone, registered with iptel.org, and I'm using my server as a simple proxy. However, no matter what SIP URL I place a call to, I get a java.net.SocketException: Invalid argument when I call Proxy.proxyTo().

To demonstrate the problem, I'm using the simple ProxyServlet code from

https://code.google.com/p/cipango/source/browse/trunk/extras/test-cipango-websocket/src/main/java/org/cipango/websocket/ProxyServlet.java?r=775

Here is the debug output that shows the offending SIP message and the stack trace when the exception occurs.

Any ideas?

Many thanks,

Chris


-------------

DEBUG qtp22218065-20 org.cipango.server.processor.TransportProcessor - handling message INVITE sip:ch...@iptel.org SIP/2.0
Call-ID: rpyvaduovjveiht@ubuntu

DEBUG qtp22218065-20 org.cipango.server.transaction.TransactionManager - handling server transaction message with tx null
INVITE sip:ch...@iptel.org SIP/2.0
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE
Call-ID: rpyvaduovjveiht@ubuntu
Contact: <sip:lau...@127.0.0.1:5080;transport=udp>
Content-Length: 302
Content-Type: application/sdp
CSeq: 511 INVITE
From: "Chris Lauwers" <sip:lau...@iptel.org>;tag=lubkf
Max-Forwards: 70
Supported: replaces,norefersub,100rel
To: <sip:ch...@iptel.org>
User-Agent: Twinkle/1.4.2
Via: SIP/2.0/UDP 127.0.0.1:5080;branch=z9hG4bKfjhasbvz;rport=5080

v=0
o=twinkle 2144333461 809606111 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=audio 8000 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

DEBUG qtp22218065-20 org.cipango.server.SipProxy - Created proxy for tx ServerTransaction {branch=z9hG4bKfjhasbvz, method=INVITE, state=PROCEEDING}
DEBUG qtp22218065-20 org.cipango.server.SipProxy - adding target sip:ch...@iptel.org to target set
DEBUG qtp22218065-20 org.cipango.server.SipProxy - Proxying to sip:ch...@iptel.org
WARN qtp22218065-20 org.cipango.server.nio.UdpConnector -
java.net.SocketException: Invalid argument
at sun.nio.ch.DatagramChannelImpl.send0(Native Method)
at sun.nio.ch.DatagramChannelImpl.sendFromNativeBuffer(DatagramChannelImpl.java:514)
at sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:491)
at sun.nio.ch.DatagramChannelImpl.send(DatagramChannelImpl.java:455)
at org.cipango.server.nio.UdpConnector$UdpConnection.send(UdpConnector.java:197)
at org.cipango.server.nio.UdpConnector$UdpConnection.send(UdpConnector.java:179)
at org.cipango.server.SipServer.sendRequest(SipServer.java:355)
at org.cipango.server.transaction.ClientTransaction.doSend(ClientTransaction.java:158)
at org.cipango.server.transaction.ClientTransaction.start(ClientTransaction.java:174)
at org.cipango.server.transaction.TransactionManager.sendRequest(TransactionManager.java:219)
at org.cipango.server.session.Session.sendRequest(Session.java:308)
at org.cipango.server.SipProxy$Branch.start(SipProxy.java:903)
at org.cipango.server.SipProxy.startProxy(SipProxy.java:433)
at org.cipango.server.SipProxy.proxyTo(SipProxy.java:296)
at com.ubicity.sip.CipangoProxyServlet.doRequest(CipangoProxyServlet.java:37)
at javax.servlet.sip.SipServlet.service(Unknown Source)
at org.cipango.server.servlet.SipServletHolder.handle(SipServletHolder.java:145)
at org.cipango.server.servlet.SipServletHandler.handle(SipServletHandler.java:180)
at org.cipango.server.security.SipSecurityHandler.handle(SipSecurityHandler.java:323)
at org.cipango.server.session.SessionHandler.handleRequest(SessionHandler.java:178)
at org.cipango.server.session.SessionHandler.handle(SessionHandler.java:67)
at org.cipango.server.handler.SipHandlerWrapper.handle(SipHandlerWrapper.java:56)
at org.cipango.server.SipServer.handle(SipServer.java:238)
at org.cipango.server.processor.SipProcessorWrapper.doProcess(SipProcessorWrapper.java:53)
at org.cipango.server.transaction.TransactionManager.doProcessRequest(TransactionManager.java:121)
at org.cipango.server.transaction.TransactionManager.doProcess(TransactionManager.java:50)
at org.cipango.server.processor.SipProcessorWrapper.doProcess(SipProcessorWrapper.java:51)
at org.cipango.server.processor.TransportProcessor.doProcess(TransportProcessor.java:95)
at org.cipango.server.SipServer$1.run(SipServer.java:223)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:589)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:520)
at java.lang.Thread.run(Thread.java:722)

[Nicolas]

Hello Chris,
I think that this is due to bad Cipango configuration: on which interfaces are
binding SIP connectors ?
If it is 127.0.0.1 like it seems to be (we could see this value in Via and
Contact), then it is wrong. It should be the public IP address.

Regards,
Nicolas

Le 30/04/2013 23:19, Chris Lauwers a �crit :

[Chris Lauwers]

Thanks Nicolas, I had (incorrectly) assumed that SipServer would automatically create UdpConnectors to listen on all the network interfaces. I added a new UdpConnector for the machine's external IP address. However, after I do that, I continue to have the same problem. Here is the log.

One question: given that I now have 2 UdpConnectors, how does the Proxy decide with UdpConnector to use to send the outgoing request?

Thanks,

Chris

---------------


INFO main org.eclipse.jetty.server.Server - jetty-9.0.0.M5
INFO main org.eclipse.jetty.server.handler.ContextHandler - started o.e.j.s.ServletContextHandler@5d5a2c{/,file:/home/lauwers/Workspace/Ubicity/html/,AVAILABLE}
INFO main org.eclipse.jetty.server.ServerConnector - Started ServerConnector@d0a64a{HTTP/1.1}{0.0.0.0:8080}
INFO main org.cipango.server.SipServer - cipango-3.0.0.M0
INFO main org.cipango.server.AbstractSipConnector - Started UdpCon...@127.0.1.1:5060
INFO main org.cipango.server.AbstractSipConnector - Started UdpCon...@192.168.28.148:5060
DEBUG qtp29676948-21 org.cipango.server.processor.TransportProcessor - handling message INVITE sip:ch...@iptel.org SIP/2.0
Call-ID: eybbavjxrurkzif@ubuntu

DEBUG qtp29676948-21 org.cipango.server.transaction.TransactionManager - handling server transaction message with tx null

INVITE sip:ch...@iptel.org SIP/2.0
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, REFER, NOTIFY, SUBSCRIBE, INFO, MESSAGE

Call-ID: eybbavjxrurkzif@ubuntu
Contact: <sip:lau...@192.168.28.148:5080;transport=udp>
Content-Length: 313
Content-Type: application/sdp
CSeq: 316 INVITE
From: "Chris Lauwers" <sip:lau...@iptel.org>;tag=fpkgx

Max-Forwards: 70
Supported: replaces,norefersub,100rel
To: <sip:ch...@iptel.org>
User-Agent: Twinkle/1.4.2

Via: SIP/2.0/UDP 192.168.28.148:5080;branch=z9hG4bKdmxmyfhe;rport=5080

v=0
o=twinkle 1947311533 1620473843 IN IP4 192.168.28.148
s=-
c=IN IP4 192.168.28.148

t=0 0
m=audio 8000 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20

DEBUG qtp29676948-21 org.cipango.server.SipProxy - Created proxy for tx ServerTransaction {branch=z9hG4bKdmxmyfhe, method=INVITE, state=PROCEEDING}
DEBUG qtp29676948-21 org.cipango.server.SipProxy - adding target sip:ch...@iptel.org to target set
DEBUG qtp29676948-21 org.cipango.server.SipProxy - Proxying to sip:ch...@iptel.org
WARN qtp29676948-21 org.cipango.server.nio.UdpConnector -

-----Original Message-----
From: cipang...@googlegroups.com [mailto:cipang...@googlegroups.com] On Behalf Of Nicolas
Sent: Thursday, May 02, 2013 12:19 AM
To: cipang...@googlegroups.com
Subject: Re: [cipango-users] problem with simple proxy code

Hello Chris,
I think that this is due to bad Cipango configuration: on which interfaces are binding SIP connectors ?
If it is 127.0.0.1 like it seems to be (we could see this value in Via and Contact), then it is wrong. It should be the public IP address.

Regards,
Nicolas

--
You received this message because you are subscribed to the Google Groups "cipango-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cipango-user...@googlegroups.com.
To post to this group, send email to cipang...@googlegroups.com.
Visit this group at http://groups.google.com/group/cipango-users?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.

[Nicolas]

Chris,
Cipango does not entirely support multihosting (allow only one connector in IPv4
and one in IPv6).
If you use two IPv4 connectors, only the first will be used to send messages.
Also, it is not possible to use wilcard address 0.0.0.0 in order to listen to
all interfaces as Via, Contact and Record-Route would not be correctly set.

Regards,
Nicolas

Le 02/05/2013 21:56, Chris Lauwers a �crit :

> Le 30/04/2013 23:19, Chris Lauwers a �crit :

[Chris Lauwers]

Thanks Nicolas,

 

So, if I understand correctly:

 

1.       A UdpConnector is tied to one single network interface, and only listens on that network interface (as opposed to listening on “IN_ADDR_ANY”)

2.       I can create multiple UdpConnectors (one for each of my network interfaces), but there is no reliably way to specify which UdpConnector will be used for outgoing traffic.

 

How does the “default” UdpConnector (the one created when you instantiate a SipServer) decide which network interface to use? On my VM, it picks the loopback address, which isn’t very useful J

 

Any suggestions for how to deal with this? Would it be possible (and safe) to add a new UdpConnector for the physical network interface, and then remove the UdpConnector for the loopback address?

 

Thanks,

 

Chris

 

-----Original Message-----
From: cipang...@googlegroups.com [mailto:cipang...@googlegroups.com] On Behalf Of Nicolas
Sent: Thursday, May 02, 2013 11:45 PM
To: cipang...@googlegroups.com
Subject: Re: [cipango-users] problem with simple proxy code

 

Chris,

[David Soulayrol]

Hi Chris.

You understand well.

By default, the Cipango configuration defines one TCP connector and one
UDP connector, both binding the same address. This address can be specified
thanks to the sip.host system property. It defaults to the loopback
address. This makes sense because it is an easy and portable way to have
a functional distribution anywhere at least for testing.

This behaviour can be changed by editing the etc/cipango.xml file in the
distribution directory. You can find other useful system properties for
the default configuration on the following page:

http://confluence.cipango.org/display/DOC/Configuring+and+Running+Cipango#ConfiguringandRunningCipango-SIPConnectors

As it was said before, you can add here other interfaces if you wish,
but there is no guarantee on the one used to output messages. With the
current implementation, the first one should be preferred.


--
David Soulayrol

[Chris Lauwers]

Thanks David. We've been using Jetty/Cipango in embedded mode. What is the recommended way to set these properties programmatically?

Thanks,

Chris

-----Original Message-----
From: cipang...@googlegroups.com [mailto:cipang...@googlegroups.com] On Behalf Of David Soulayrol
Sent: Monday, May 06, 2013 12:49 AM
To: cipang...@googlegroups.com
Subject: Re: [cipango-users] problem with simple proxy code

[David Soulayrol]

Hello.

> Thanks David. We've been using Jetty/Cipango in embedded mode. What is
> the recommended way to set these properties programmatically?

Sorry, I failed to notice this from your previous mails.

From your previous mail, you seem to have not noticed that the server
comes with a default connector only if you call its constructor taking a
port as argument. So the following snippet creates a server with exactly
one custom UDP connector.

SipServer server = new Server();
UdpConnector connector = new UdpConnector();
connector.setHost("my.example.com");
connector.setPort(5060);
server.addConnector(connector);


--
David Soulayrol

[Chris Lauwers]

Thanks David. That still leaves me with 2 UdpConnectors, correct? Presumably outgoing messages will still be sent using the loopback interface (under the assumption that the loopback interface is associated with the first UdpConnector). Is there a way to remove the UdpConnector associated with the loopback interface?

Thanks,

Chris

-----Original Message-----
From: cipang...@googlegroups.com [mailto:cipang...@googlegroups.com] On Behalf Of David Soulayrol
Sent: Monday, May 06, 2013 8:26 AM
To: cipang...@googlegroups.com
Subject: Re: [cipango-users] problem with simple proxy code

[David Soulayrol]

On 2013.05.06 15:39:22 +0000, Chris Lauwers wrote:

> Thanks David. That still leaves me with 2 UdpConnectors, correct?

No. I wrote that the default connector is only created if you call
SipServer(int), the argument being the port for this connector.

So with the snippet I provided, using the default SipServer constructor
with no argument, you really only have the UDP connector you explicitly
configure.

--
David Soulayrol

[Chris Lauwers]

Sorry, I missed that. Thanks for clarifying.

Chris

-----Original Message-----
From: cipang...@googlegroups.com [mailto:cipang...@googlegroups.com] On Behalf Of David Soulayrol
Sent: Monday, May 06, 2013 8:56 AM
To: cipang...@googlegroups.com
Subject: Re: [cipango-users] problem with simple proxy code

[Chris Lauwers]

Hi Nicolas,

 

In an earlier email, you stated:

 

>  Also, it is not possible to use wilcard address 0.0.0.0 in order to listen to all interfaces as Via, Contact and Record-Route would not be correctly set.

 

I assume that Via, Contact, and Record-Route could be set to reflect the IP address of the UdpConnector on which the message came in or on which an outgoing message is sent. I'm curious if the SIP standard specifies how to properly deal with this. Let's consider, for example, a dual-homed proxy server that accepts a SIP message on one interface and decides to send it out on a second interface:

 

-          Would it be correct to insert two Via headers, one for incoming interface and one for the outgoing interface?

-          How about Record-Route? Would it be correct in this case to have the Record-Route header reflect the outgoing interface?

 

I understand that Cipango doesn’t currently support any of this. I’m just curious what the “standard” way of dealing with multi-homed machines would be.

 

Thanks,

 

Chris

[Cipango SIP AS]

Hi Chris, 

Via is only inserted in outgoing messages, so double Via is not an option. Nevertheless, it is easy to keep track of incoming interface in the transaction context or in a Via parameter for a stateless SIP proxy.

Record-route is more of an issue since the Route information may be used by both sides which may be in different networks or even use different versions of IP (v4/v6). This is usually solved by using double record-route technique as described in:

http://tools.ietf.org/html/rfc5658

Regards,

Thomas