Re: [reSIProcate-users] Forcing an Outbound Transport-Type
Ok, here is my trivial patch allowing the transport to be selected from
the Via-header.
If the transport part of the Via is set, it will override any transport
selected from DNS. So, if a wrong transport type is specified, the
connection will fail.
Gabriel
Am 09.05.2012 15:02, schrieb Scott Godin:
Ah - I missed the use of target when populating the source tuple. That
logic in the code does makes sense to me though. If your target is
specifying a particular transport type, then you really need to be sending
on that transport. For example: You can't really send to a request uri
specifying sip:<domain>;transport=TCP over UDP - the same way you can't
send to an IPv6 address using IPv4. If you changes this, I'm worried that
things might break for other scenarios. That being said if the transport
type in the tuple was selected due to SRV priority, then it would be valid
to ignore it and use another (lower priority) transport - but I don't think
there is a way for the TransportSelector to know this - since the DNS logic
has already run and selected a destination tuple. And since you have both
transport types defined, it will select whichever type has the highest
priority. Is it an option to remove the UDP transport entirely from the
stack? If not I think there would need to be some new logic in resip that
allows dum to pass down a subset of valid transports for a particular
request, and let the stack resolve the DNS queries and do transport
selection appropriately using this subset, instead of looking across all
transports added to the stack.
Scott
On Wed, May 9, 2012 at 7:44 AM, Gabriel Hege<" gabriel-mailinglists"@gmx.de
wrote:
Hi Scott,
thanks for the quick reply.
Stepping through the code (resiprocate version 1.7.1) I found the problem
in findTransportByVia(), but the respective code has not changed in trunk.
The problem is findTransportByVia() sets the transport type in the source
tuple, to the transport type found in the target. I think if a Via is
present with the transport set, this should be used.
I will try to provide a patch.
Best regards,
Gabriel
Am 08.05.2012 23:32, schrieb Scott Godin:
Hi Gabriel,
Looking through the code in SVN head/trunk, I can't see anything
obviously wrong with what you are trying (there may have been bugs in
older releases). Are you able to trace through findTransportByVia and
see why it is failing to select your TCP transport? Examining Debug
level logs should also help to understand why as well.
Scott
On Tue, May 8, 2012 at 4:56 PM, Gabriel Hege
<gabriel-mailinglists@xxxxxx<mailto:gabriel-mailinglists@**gmx.de<gabriel-mailinglists@xxxxxx>>>
wrote:
Hi,
What is the proper way to force a transport type (e.g. TCP) for an
outgoing request - or even better for all request from a certain
UserProfile?
The comments in Profile.hxx suggest that somebody thought about
using setOverrideHostAndPort() to also populate the Via entries, but
it is not implemented.
I tried setting the transport for the first Via of a request like this:
invite_msg = mp_dum->makeInviteSession( m_to_addr, m_profile,
&m_sdp, new MyAppDialogSet(*mp_dum) );
invite_msg->header(h_Vias).__**front().transport() = "TCP";
mp_dum->send(invite_msg);
but the message is still sent over the wire as UDP, although it
contains the following header:
Via: SIP/2.0/TCP
141.22.27.150:5060;branch=__**z9hG4bK-d8754z-__**
bf3a78252072422c-1---d8754z-;_**_rport
findTransportByVia() and findTransportBySource() are actually called
in the TransportSelector, since I do have
setFixedTransportInterface() set for the used profile.
Can anybody give me some advice please?
Thank you,
gabriel
______________________________**___________________
resiprocate-users mailing list
resiprocate-users@resiprocate.**__org
<mailto:resiprocate-users@**resiprocate.org<resiprocate-users@xxxxxxxxxxxxxxx>
List Archive:
http://list.resiprocate.org/__**archive/resiprocate-users/<http://list.resiprocate.org/__archive/resiprocate-users/>
<http://list.resiprocate.org/**archive/resiprocate-users/<http://list.resiprocate.org/archive/resiprocate-users/>
______________________________**_________________
resiprocate-users mailing list
resiprocate-users@resiprocate.**org<resiprocate-users@xxxxxxxxxxxxxxx>
List Archive:
http://list.resiprocate.org/**archive/resiprocate-users/<http://list.resiprocate.org/archive/resiprocate-users/>
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
Index: resip/stack/TransportSelector.cxx
===================================================================
--- resip/stack/TransportSelector.cxx (revision 9670)
+++ resip/stack/TransportSelector.cxx (working copy)
@@ -563,13 +563,14 @@
assert(!msg->const_header(h_Vias).empty());
const Via& via = msg->const_header(h_Vias).front();
- if (via.sentHost().empty())
+ if (via.sentHost().empty() && via.transport().empty())
{
return NULL;
}
// XXX: Is there better way to do below (without the copy)?
- source = Tuple(via.sentHost(), via.sentPort(), target.ipVersion(),
target.getType());
+ source = Tuple(via.sentHost(), via.sentPort(), target.ipVersion(),
+ via.transport().empty() ? target.getType() :
toTransportType(via.transport()) );
if ( target.mFlowKey!=0 && (source.getPort()==0 || source.isAnyInterface())
)
{
@@ -585,6 +586,7 @@
// transmit() will later use determineSourceInterface() to
// get the actual interface to populate the Contact & Via headers.
// Not sure if we should support this case or just assert.
+ // This should be supported, in case only the transport part of the Via
is set
msg->header(h_Vias).front().sentHost().clear();
}