[OpenSIPS-Users] Transport identification
Daniel Goepp
dan at goepp.net
Sat Mar 6 19:42:20 CET 2010
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
More information about the Users
mailing list