[reSIProcate] Decorator reporting wrong source port

[Scott Godin]

The language in the base SIP RFC has UA's establish TCP/TLS connections in
both directions.  So the contact header must list the port we are listening
on for TCP/TLS connections.  If you want to have the SIP stack share a
single connection for messages in both directions, you need to start
looking at RFC5626, or coming up with your own custom way for doing this
(which I wouldn't recommend).  Websocket clients use RFC5626, so the
contact header isn't even used.  repro supports RFC5626 and it supports a
mode where you can treat registrations like the UA's support RFC5626 even
though they may not (called something like FlowTokenHack).

DUM has the ability to be able to be a RFC5626 enabled client (see
dum/test/basicClient example).  You really need to read RFC5626 to
understand this stuff better though.

Here is a wiki page with some info:
https://www.resiprocate.org/DUM_Client_Outbound_Support

Best Regards,
Scott

On Tue, Feb 20, 2018 at 11:52 AM, Diego Carvalho Domingos <
ddomingos at daitangroup.com> wrote:

> Hi Dario, thanks for answering
>
> I totally agree with you on this:
>
> "For any other server-initiated transaction in dialog, for example
> BYE/200, TLS server should reuse the SAME connection toward TLS client
> otherwise server couldn’t know if it is able to contact client."
>
> But that's not what is happening. The TLS UAS sometimes open a new
> connection on 5061 to send a BYE and sometimes doesn't and then the BYE
> never arrives. Then I saw that Bria does this change on the contact header
> (I tried when it was registered using TCP, but I guess it would be the same
> for TLS).
>
> So, this is the second time you guys point me to this RFC 5626. The other
> time was a similar question, but about the fact websocket clients put an
> invalid contact header and I wanted to get the actual connection IP/port to
> send the BYE (exact same problem in the opposite direction). So, could you
> explain how I use this RFC in DUM? (in the response for my other e-mail,
> Scott also pointed repro. Can I use this in DUM?). Also, regardless if this
> is the right thing to do or not, isn't resiprocate reporting an incorrect
> port in the decorator? Thanks again.
>
>
>
> Diego Carvalho Domingos
>
>
>
> *From:* Dario Bozzali [mailto:Dario.Bozzali at ifmgroup.it]
> *Sent:* Tuesday, February 20, 2018 5:13 AM
> *To:* Diego Carvalho Domingos <ddomingos at daitangroup.com>
> *Cc:* resiprocate-devel at resiprocate.org
> *Subject:* RE: Decorator reporting wrong source port
>
>
>
> Hello Diego,
>
> I don’t undertand why you want to set actual port in Contact header, so
> I’ll try to explain my point of view of the matter.
>
> If you are writing a TLS client using reSIProcate or any other SIP
> library, receiving TLS server should send status message for INVITE through
> established TLS connection (in this case actual port is not relevant).
>
> For any other server-initiated transaction in dialog, for example BYE/200,
> TLS server should reuse the SAME connection toward TLS client otherwise
> server couldn’t know if it is able to contact client.
>
> This is true even if you write the right/actual port in Contact header of
> INVITE message because you don’t have to create another TLS connection from
> server to client on that port. Actually TLS client could be just only a TLS
> client, that cannot act as server and receive connections on TLS port, even
> 5061, because it doesn’t have server certificate with private key, for
> example.
>
> As far as I know you should reuse the same connection in a similar way
> that you act using RFC 5626 “Managing Client-Initiated Connections in the
> Session Initiation Protocol (SIP)”.
>
> Try to have a look at method ResponseContext::getInboundFlowToken() in
> repro.
>
> Hope that the things I wrote are right (Scott could be more precise), I
> hope that this could help you.
>
> Best regards,
>
> Dario
>
>
>
> *From:* resiprocate-devel [mailto:resiprocate-devel-
> bounces at resiprocate.org <resiprocate-devel-bounces at resiprocate.org>] *On
> Behalf Of *Diego Carvalho Domingos
> *Sent:* Monday, 19 February, 2018 21:30
> *To:* resiprocate-devel at resiprocate.org
> *Subject:* [reSIProcate] Decorator reporting wrong source port
>
>
>
> Hi all,
> I want to populate the contact header of an INVITE message with the actual
> port used by the stack to establish a TLS connection instead of the default
> 5061. The decorator example does exactly that for the SDP so I tried to use
> that code but source.getPort() returns 5061. I investigated the code and
> found that initially the method determineSourceInterface is used but the
> port is set to 0 because via.sentPort() is 0. Then, because of that, the
> port is set to transport->port(), which I think is the same transport that
> is setup on resiprocate initialization (which of course had the port set to
> 5061). How do I get the actual port used by the stack to initiate the TLS
> connection? Is this a bug in reciprocate? I appreciate any help. Thanks
>
>
>
> Diego Carvalho Domingos
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20180220/22146bd7/attachment.htm>