Re: [reSIProcate-users] Forcing an Outbound Transport-Type
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>> 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) );
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>
List Archive:
http://list.resiprocate.org/__archive/resiprocate-users/
<http://list.resiprocate.org/archive/resiprocate-users/>