[OpenSIPS-Users] OpenSIPS Retain Protocol on relay

Wed Jan 25 02:09:40 CET 2012

Thanks for trying. In addition, here's the summary of a packet capture of
me trying to call myself:

http://pastebin.com/raw.php?i=3iczgtXb

 X-Lite = x.x.x.x
 OpenSIPS = y.y.y.y
 FreeSWITCH = z.z.z.z

TCP  1   0.000000 x.x.x.x -> y.y.y.y SIP/SDP Request: INVITE
sip:1111 at y.y.y.y;transport=tcp, with session description
TCP  2   0.000042 y.y.y.y -> x.x.x.x TCP sip > 59498 [ACK] Seq=1
Ack=982 Win=864 Len=0
TCP  3   0.000800 y.y.y.y -> x.x.x.x SIP Status: 100 Giving a try
TCP  4   0.000948 y.y.y.y -> z.z.z.z TCP 41695 > sip [SYN] Seq=0
Win=5840 Len=0 MSS=1460 TSV=31556561 TSER=0 WS=6
TCP  5   0.001335 z.z.z.z -> y.y.y.y TCP sip > 41695 [SYN, ACK] Seq=0
Ack=1 Win=14480 Len=0 MSS=1460 TSV=31542864 TSER=31556561 WS=6
TCP  6   0.001385 y.y.y.y -> z.z.z.z TCP 41695 > sip [ACK] Seq=1 Ack=1
Win=5888 Len=0 TSV=31556562 TSER=31542864
TCP  7   0.001696 y.y.y.y -> z.z.z.z SIP/SDP Request: INVITE
sip:1111 at z.z.z.z;transport=tcp, with session description
TCP  8   0.001855 z.z.z.z -> y.y.y.y TCP sip > 41695 [ACK] Seq=1
Ack=1233 Win=16960 Len=0 TSV=31542865 TSER=31556562
TCP  9   0.002719 z.z.z.z -> y.y.y.y SIP Status: 100 Trying
TCP 10   0.002732 y.y.y.y -> z.z.z.z TCP 41695 > sip [ACK] Seq=1233
Ack=491 Win=6912 Len=0 TSV=31556563 TSER=31542865
TCP 11   0.215286 x.x.x.x -> y.y.y.y TCP 59498 > sip [ACK] Seq=982
Ack=325 Win=4150 Len=0
TCP 12   0.712565 z.z.z.z -> y.y.y.y TCP 48269 > sip [SYN] Seq=0
Win=14600 Len=0 MSS=1460 TSV=31543575 TSER=0 WS=6
TCP 13   0.712628 y.y.y.y -> z.z.z.z TCP sip > 48269 [SYN, ACK] Seq=0
Ack=1 Win=5792 Len=0 MSS=1460 TSV=31557273 TSER=31543575 WS=6
TCP 14   0.712944 z.z.z.z -> y.y.y.y TCP 48269 > sip [ACK] Seq=1 Ack=1
Win=14656 Len=0 TSV=31543576 TSER=31557273
TCP 15   0.712997 z.z.z.z -> y.y.y.y SIP/SDP Request: INVITE
sip:1111 at x.x.x.x:59498;rinstance=2e3da39d713a676d;transport=TCP, with
session description
TCP 16   0.713009 y.y.y.y -> z.z.z.z TCP sip > 48269 [ACK] Seq=1
Ack=1383 Win=8704 Len=0 TSV=31557273 TSER=31543576
TCP 17   0.714476 y.y.y.y -> z.z.z.z SIP Status: 100 Giving a try
TCP 18   0.714635 z.z.z.z -> y.y.y.y TCP 48269 > sip [ACK] Seq=1383
Ack=315 Win=15680 Len=0 TSV=31543577 TSER=31557275
UDP 19   0.714713 y.y.y.y -> x.x.x.x SIP/SDP Request: INVITE
sip:1111 at x.x.x.x:59498;rinstance=2e3da39d713a676d;transport=TCP, with
session description
UDP 20   1.217530 y.y.y.y -> x.x.x.x SIP/SDP Request: INVITE
sip:1111 at x.x.x.x:59498;rinstance=2e3da39d713a676d;transport=TCP, with
session description
UDP 21   2.219539 y.y.y.y -> x.x.x.x SIP/SDP Request: INVITE
sip:1111 at x.x.x.x:59498;rinstance=2e3da39d713a676d;transport=TCP, with
session description

You can see that OpenSIPS is trying to send the request as UDP even though
it originally came from FreeSWITCH as TCP.

Regards,
William

On Tue, Jan 24, 2012 at 4:28 PM, <duane.larson at gmail.com> wrote:

> Well hell. Thats all I know to do just from looking at the documentation.
> Hopefully one of the other guys can help when they wake up in their
> respective timezones.
>
> Sorry I couldn't help.
>
>
>
> On , William Edwards <shadowapex at gmail.com> wrote:
> > Hey Duane,
> >
> > Yes, I tried using force_send_socket, but it still sends the request as
> UDP instead of the original TCP. I noticed in the documentation it says
> that if the protocol doesn't match, the closest socket of the same protocol
> is used:
> >
> >
> >
> >
> >
> > "If the protocol doesn't match (e.g. UDP message "forced" to a TCP
> socket) the closest socket of the same protocol is used.
> >
> > "
> >
> > Regards,
> > William
> >
> >
> > On Tue, Jan 24, 2012 at 4:14 PM, duane.larson at gmail.com> wrote:
> >
> >
> >
> >
> > What about force_send_socket
> >
> >
> > http://www.opensips.org/Resources/DocsCoreFcn#toc111
> >
> >
> >
> >
> >
> > Have you tried that yet.
> >
> >
> >
> >
> >
> > force_send_socket(udp:192.168.1.10:5060);
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On , William Edwards shadowapex at gmail.com> wrote:
> >
> >
> > > In my attempt to resolve this problem I have also already come across
> that article. Unfortunately the t_relay function does not support variables
> as parameters, so I am not able to put in the full uri (e.g.
> tcp:70.232.x.x:55085) in the function. From this article (
> http://openser.org/pipermail/users/2010-March/011638.html), it was
> suggested to rewrite the $du instead, however I don't believe it is
> possible to specify the protocol in the $du.
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > Regards,
> >
> >
> > > William
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > On Tue, Jan 24, 2012 at 3:12 PM, duane.larson at gmail.com> wrote:
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > I did a search for "tcp" on Nabble's OpenSIPS section and just found
> this
> >
> >
> > >
> >
> >
> > >
> http://opensips-open-sip-server.1449251.n2.nabble.com/How-to-change-transport-protocol-of-R-URI-td6376471.html
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > I would say you need to use t_relay() with parameters.
> >
> >
> > >
> >
> >
> > > Hope that helps.
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > On , William Edwards shadowapex at gmail.com> wrote:
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > > Hi,
> >
> >
> > > >
> >
> >
> > > > Thanks for your reply. I've looked into $fs, but I haven't been able
> to find any concise documentation about how I can use it to force the
> protocol to TCP. It's really unclear as to why OpenSIPS would be rewritting
> the TCP message to UDP in the first place. Is there no way to configure
> OpenSIPS to relay the message using the same protocol that it was received?
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > Regards,
> >
> >
> > > > William
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > On Tue, Jan 24, 2012 at 10:26 AM, duane.larson at gmail.com> wrote:
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > > > Perhaps you need this somewhere in your script
> >
> >
> > > >
> >
> >
> > > > $fs Forced socket:
> http://www.opensips.org/Resources/DocsCoreVar16#toc38
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > On , William Edwards shadowapex at gmail.com> wrote:
> >
> >
> > > > > Hi,
> >
> >
> > > > >
> >
> >
> > > > > We currently have two Freeswitch boxes behind OpenSIPS which
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > > is acting as a SIP proxy/load balancer. Right now we're facing a
> problem
> >
> >
> > > > > where OpenSIPS is rewriting incoming INVITE messages from our
> >
> >
> > > > > Freeswitch servers from TCP to UDP. This, of course, is causing a
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > > problem because the client has registered using TCP, and incoming
> calls
> >
> >
> > > > > are being sent to it over UDP.
> >
> >
> > > > >
> >
> >
> > > > >
> >
> >
> > > > > This is an overview of what is happening:
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > > > Freeswitch -TCP-> OpenSIPS -UDP-> Client UA (listening on TCP)
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > >
> >
> >
> > > > > We would like OpenSIPS to retain the original protocol that the
> message was received. Is there any way this is possible?
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > > >
> >
> >
> > > > >
> >
> >
> > > > >
> >
> >
> > > > >
> >
> >
> > > > > My current OpenSIPS configuration can be found here:
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > > http://pastebin.com/DSU1f2VS
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > > >
> >
> >
> > > > > Regards,
> >
> >
> > > > > William
> >
> >
> > > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > > _______________________________________________
> >
> >
> > > >
> >
> >
> > > > Users mailing list
> >
> >
> > > >
> >
> >
> > > > Users at lists.opensips.org
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > >
> >
> >
> > > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > _______________________________________________
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > Users mailing list
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > Users at lists.opensips.org
> >
> >
> > >
> >
> >
> > >
> >
> >
> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > >
> >
> >
> > _______________________________________________
> >
> >
> > Users mailing list
> >
> >
> > Users at lists.opensips.org
> >
> >
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> >
> >
> >
> >
> >
> >
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20120124/22d6df52/attachment-0001.htm>