[OpenSIPS-Users] Transport identification

[Daniel Goepp]

Thanks for the info.  Looks like I'm dealing with two external problems
then.  A device that is not doing what it should by specifying the
transport, and this other server we are communicating with that regardless
of if it get's a UDP request, it will first try TCP on the way out.  Ah the
joy of working around incompatible devices and servers.  I guess this is why
we like OpenSIPS so much, it's flexible enough to fix other people's
problems ;)

-dg


On Sat, Mar 6, 2010 at 12:27 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Daniel Goepp wrote:
> > We actually use record_route_preset not record_route, I would have
> > presumed the logic would be the same for both though regarding this.
> rr_preset() is for setting your own rr header, overriding the automatic
> building of  the headers.  So you have to red pill - let opensips to do
> the job - or the blue pill - you do you yourself, but do it from A to Z
>
> > I do not explicitly set double_rr, so it should be the default of on
> > as you point out.  My work around of testing and setting manually does
> > appear to be working now.  I also wonder about what the default
> > protocol / priority would be to use on a call.  For example a SIP URI
> > call where you don't know if the called party is UDP or TCP, it
> > appears to default to UDP.
> if there is not protocol indication (like SIPS scheme or transport
> param), it is UDP - that is what RFC3261 says
> > However if the endpoint I'm calling from is using TCP, I would prefer
> > to have the outbound attempt first try TCP, then go to UDP if it fails.
> if you receive the call over TCP and the caller requests TCP for
> delivery, you should have the transport=TCP param in the received RURI.
> The presence of this param will force opensips to use the indicated
> transport for sending the call out.
> Se simple fact you receive the call over TCP does not mean anything -
> what is important is what protocol is required via RURI.
>
> Regards,
> Bogdan
> > The system we are sending calls to actually just prefers TCP all the
> > time, and then fails over to UDP if it can't complete the call.  We
> > are still experimenting with this, but due to the large packet sizes
> > we are seeing with video, TCP is working better for us in most
> situations.
> >
> > Thanks
> >
> > -dg
> >
> >
> > On Fri, Mar 5, 2010 at 11:50 AM, Bogdan-Andrei Iancu
> > <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
> >
> >     Hi Daniel,
> >
> >     But record_route() will automatically do double routing if a proto
> >     / ip
> >     / port change is detected between the inbound and outbound interface.
> >     You need to have the "double_rr" enabled (which is by default).
> >
> >     Could you check how the RR added by OpenSIPS looks like ?
> >
> >     Regards,
> >     Bogdan
> >
> >     Daniel Goepp wrote:
> >     > Oh man...then TWO seconds after sending this, I find:
> >     >
> >     > if(proto==TCP)
> >     > {
> >     > log("the SIP message was received over TCP\n");
> >     > };
> >     >
> >     > However my other comment of perhaps this should be handled
> >     > automatically by OpenSIPS still stands :)
> >     >
> >     > Thanks
> >     >
> >     > -dg
> >     >
> >     >
> >     > On Fri, Mar 5, 2010 at 9:18 AM, Daniel Goepp <dan at goepp.net
> >     <mailto:dan at goepp.net>
> >     > <mailto:dan at goepp.net <mailto:dan at goepp.net>>> wrote:
> >     >
> >     >     We are doing some interop work with another switch, and it is
> >     >     having some trouble with TCP vs UDP.  Because of the packet
> size
> >     >     for these specific calls we need to do them TCP.  However the
> >     >     record-route in our 200 OK has no transport set, and
> >     according to
> >     >     the RFC, no transport for SIP default is UDP.  This means
> >     that all
> >     >     our signaling is TCP, until we get an ACK back from this
> >     box, and
> >     >     it then is UDP, but too big and breaks the call.  I have
> >     found the
> >     >     add_rr_param, so I could do a
> >     add_rr_param(";transport=tcp"), but
> >     >     I only want to do this for calls that are currently using
> >     TCP.  I
> >     >     looked for a function to test the protocol used, but
> >     couldn't find
> >     >     one.  Anyone know what it is?  Also, it would seem the
> >     appropriate
> >     >     thing for OpenSIPS to do would be to automatically put the
> >     >     ;transport=xxx in the RR based on the current protocol of the
> >     >     dialog.  Thoughts on that?
> >     >
> >     >     Thanks
> >     >
> >     >     -dg
> >     >
> >     >
> >     >
> >
> ------------------------------------------------------------------------
> >     >
> >     > _______________________________________________
> >     > Users mailing list
> >     > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >     >
> >
> >
> >     --
> >     Bogdan-Andrei Iancu
> >     www.voice-system.ro <http://www.voice-system.ro>
> >
> >
> >     _______________________________________________
> >     Users mailing list
> >     Users at lists.opensips.org <mailto: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
> >
>
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
>
>
> _______________________________________________
> 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/20100306/f2787420/attachment-0001.htm