[jitsi-users] Incorrect port in Contact header for TCP connections


#1

Hello everyone,

There is a problem with how Jitsi registers with a PBX (Asterisk):

<--- Received SIP request (491 bytes) from TCP:10.101.100.10:18372 --->

REGISTER sip:10.101.10.1;transport=tcp SIP/2.0

Call-ID: c3587e7b7f0417317a1ab84a3cff396c@0:0:0:0:0:0:0:0

CSeq: 1 REGISTER

···

From: "JDoe" <sip:555@10.101.10.1>;tag=100e838e

To: "JDoe" <sip:555@10.101.10.1>

Via: SIP/2.0/TCP
10.101.100.10:18372;branch=z9hG4bK-353433-2f76bf850dbfc60bf086f8e81aea47de

Max-Forwards: 70

User-Agent: Jitsi2.8.5426Windows 7

Expires: 600

Contact: "JDoe"
<sip:555@10.101.100.10:18372;transport=tcp;registering_acc=10_101_10_1>;expi
res=600

Content-Length: 0

Here Via says "send the responses to my_ip:18372" and Contact says "send new
requests (INVITE, NOTIFY, etc.), establishing a new TCP session, to.. the
same my_ip:18372". Nevertheless Jitsi listens on all 3 standard SIP ports:
tcp/5060, tcp/5061 & udp/5060 on 0.0.0.0 (they are specified in the global
SIP configuration section), BUT the 18372 (random) port appears in netstat
as ESTABLISHED, *not* LISTENING and it doesn't accept new incoming
connections so Asterisk gets "connection refused" when trying to communicate
with Jitsi establishing a new connection (when not reusing the initial
connection).

So, Jitsi expects incoming connections on port 5060, but specifies the
incoming port as 18372 in Contact field. In this case, Contact should say
my_ip:5060 or omit the port entirely for the default value to be applied.

According to the SIP RFC: "While the Via header field tells other elements
where to send the response, the Contact header field tells other elements
where to send future requests."

There was a discussion of this issue at asterisk and PJSIP mailinglists:
https://issues.asterisk.org/jira/browse/ASTERISK-24889 and
http://comments.gmane.org/gmane.comp.voip.pjsip/19202 as initially it was
suspected as a problem of Asterisk/PJSIP as it could not communicate with
Jitsi endpoints over TCP.

Regards,

Anatoli


#2

I'm not familiar enough with the RFCs to make a qualified comment about how the headers should look like. Emil?

What I can say though: it will in almost all circumstances be impossible for Asterisk to connect to a client over TCP. There's usually the host firewall, NAT and a gateway/border firewall in between Asterisk and the client.
In the case of TLS (which isn't different in terms of which SIP data is sent over wire), the client would even need to present a valid certificate.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

Le 16.12.2015 à 06:11, Anatoli <me@anatoli.ws> a écrit :

Hello everyone,

There is a problem with how Jitsi registers with a PBX (Asterisk):

<--- Received SIP request (491 bytes) from TCP:10.101.100.10:18372 --->
REGISTER sip:10.101.10.1;transport=tcp SIP/2.0
Call-ID: c3587e7b7f0417317a1ab84a3cff396c@0:0:0:0:0:0:0:0
CSeq: 1 REGISTER
From: "JDoe" <sip:555@10.101.10.1>;tag=100e838e
To: "JDoe" <sip:555@10.101.10.1>
Via: SIP/2.0/TCP 10.101.100.10:18372;branch=z9hG4bK-353433-2f76bf850dbfc60bf086f8e81aea47de
Max-Forwards: 70
User-Agent: Jitsi2.8.5426Windows 7
Expires: 600
Contact: "JDoe" <sip:555@10.101.100.10:18372;transport=tcp;registering_acc=10_101_10_1>;expires=600
Content-Length: 0

Here Via says "send the responses to my_ip:18372" and Contact says "send new requests (INVITE, NOTIFY, etc.), establishing a new TCP session, to.. the same my_ip:18372". Nevertheless Jitsi listens on all 3 standard SIP ports: tcp/5060, tcp/5061 & udp/5060 on 0.0.0.0 (they are specified in the global SIP configuration section), BUT the 18372 (random) port appears in netstat as ESTABLISHED, *not* LISTENING and it doesn't accept new incoming connections so Asterisk gets "connection refused" when trying to communicate with Jitsi establishing a new connection (when not reusing the initial connection).

So, Jitsi expects incoming connections on port 5060, but specifies the incoming port as 18372 in Contact field. In this case, Contact should say my_ip:5060 or omit the port entirely for the default value to be applied.

According to the SIP RFC: "While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests."

There was a discussion of this issue at asterisk and PJSIP mailinglists: https://issues.asterisk.org/jira/browse/ASTERISK-24889 and http://comments.gmane.org/gmane.comp.voip.pjsip/19202 as initially it was suspected as a problem of Asterisk/PJSIP as it could not communicate with Jitsi endpoints over TCP.

Regards,
Anatoli

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#3

Ingo,

Thanks for your reply. There certainly may be situations where a PBX and an endpoint won't have a direct connection and there are (sometimes complex) workarounds for this scenario.

Nevertheless there are a lot of cases where they do have a direct connection (LAN, VPN, etc.). And in these situations, an incorrectly formed Contact header impedes a correct functioning of the SIP notification mechanism.

And according to the RFC 3261 (SIP: Session Initiation Protocol, https://www.ietf.org/rfc/rfc3261.txt, 6th paragraph on page 12), "Contact [header] contains a SIP or SIPS URI that represents a direct route to contact [an endpoint]".

A fix for this issue is simple: when preparing the Contact header, a client just has to specify the listening port for the connection type in use instead of an outgoing port.

Regards,

Anatoli

···

From: users [mailto:users-bounces@jitsi.org] On Behalf Of Ingo Bauersachs
Sent: Tuesday, December 15, 2015 21:06
To: Jitsi Users
Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP connections

I'm not familiar enough with the RFCs to make a qualified comment about how the headers should look like. Emil?

What I can say though: it will in almost all circumstances be impossible for Asterisk to connect to a client over TCP. There's usually the host firewall, NAT and a gateway/border firewall in between Asterisk and the client.

In the case of TLS (which isn't different in terms of which SIP data is sent over wire), the client would even need to present a valid certificate.

Freundliche Grüsse,

Ingo Bauersachs

-- sent from my mobile

Le 16.12.2015 à 06:11, Anatoli <me@anatoli.ws> a écrit :

Hello everyone,

There is a problem with how Jitsi registers with a PBX (Asterisk):

<--- Received SIP request (491 bytes) from TCP:10.101.100.10:18372 --->

REGISTER sip:10.101.10.1;transport=tcp SIP/2.0

Call-ID: c3587e7b7f0417317a1ab84a3cff396c@0:0:0:0:0:0:0:0

CSeq: 1 REGISTER

From: "JDoe" <sip:555@10.101.10.1>;tag=100e838e

To: "JDoe" <sip:555@10.101.10.1>

Via: SIP/2.0/TCP 10.101.100.10:18372;branch=z9hG4bK-353433-2f76bf850dbfc60bf086f8e81aea47de

Max-Forwards: 70

User-Agent: Jitsi2.8.5426Windows 7

Expires: 600

Contact: "JDoe" <sip:555@10.101.100.10:18372;transport=tcp;registering_acc=10_101_10_1>;expires=600

Content-Length: 0

Here Via says "send the responses to my_ip:18372" and Contact says "send new requests (INVITE, NOTIFY, etc.), establishing a new TCP session, to.. the same my_ip:18372". Nevertheless Jitsi listens on all 3 standard SIP ports: tcp/5060, tcp/5061 & udp/5060 on 0.0.0.0 (they are specified in the global SIP configuration section), BUT the 18372 (random) port appears in netstat as ESTABLISHED, *not* LISTENING and it doesn't accept new incoming connections so Asterisk gets "connection refused" when trying to communicate with Jitsi establishing a new connection (when not reusing the initial connection).

So, Jitsi expects incoming connections on port 5060, but specifies the incoming port as 18372 in Contact field. In this case, Contact should say my_ip:5060 or omit the port entirely for the default value to be applied.

According to the SIP RFC: "While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests."

There was a discussion of this issue at asterisk and PJSIP mailinglists: https://issues.asterisk.org/jira/browse/ASTERISK-24889 and http://comments.gmane.org/gmane.comp.voip.pjsip/19202 as initially it was suspected as a problem of Asterisk/PJSIP as it could not communicate with Jitsi endpoints over TCP.

Regards,

Anatoli

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#4

Hey folks,

This is a tricky topic. I have a lot of thoughts written below but my short answer is that things are currently implemented the right-est possible way in Jitsi ... considering the broken Internet we live in :).

The part that surprises me is that Asterisk has been working in a compatible for for the past 15 years so I am curious why a change is now being considered.

Here is some more thoughts about this:

The whole idea in 3261 about how clients should send their connection tuples over signalling is inherently broken in today's internet. It may make some amount of sense for server-to-server deployments. It could also work for intra-LAN/VPN communication but it is widely known to be broken for all other scenarios.

SIP outbound (RFC 5626) tries to solve this and it describes the problem the following way:
    However, in a large number
    of real deployments, many practical considerations, such as the
    existence of firewalls and Network Address Translators (NATs) or the
    use of TLS with server-provided certificates, prevent servers from
    connecting to User Agents in this way.

For years now the send-responses-to-via-and-requests-to-contact parts of 3261 have been ignored by SIP services serving clients connecting from the Internet. Every major SIP service out there, Twilio, OVH, ippi.com, iptel.org ..., all of them more or less ignore Contact and Via addresses and and reuse the connections they received from the client.

SIP wouldn't be working over the Internet if they weren't. This is why RFC5265 was written.

More inline:

Ingo,

Thanks for your reply. There certainly may be situations where a PBX and
an endpoint won't have a direct connection and there are (sometimes
complex) workarounds for this scenario.

We are not just talking about some cases here. Except for intraLAN connections the IP address and port that come with SIP requests would never work because of the reasons pointed above. Not even for public IPs.

Nevertheless there are a lot of cases where they do have a direct
connection (LAN, VPN, etc.). And in these situations, an incorrectly
formed Contactheader impedes a correct functioning of the SIP
notification mechanism.

Pooling connections and reusing sockets works just fine for these cases.

And according to the RFC 3261 (SIP: Session Initiation Protocol,
https://www.ietf.org/rfc/rfc3261.txt, 6th paragraph on page 12),
"/Contact [header] contains a SIP or SIPS URI that represents a direct
route to contact [an endpoint]/".

A fix for this issue is simple: when preparing the Contactheader, a
client just has to specify the listening port for the connection type in
use instead of an outgoing port.

I can assure you that nothing in there is simple :).

This is actually exactly what we were doing about 8 years ago and we explicitly changed it. The reason back then was that when servers needed to send requests back to Jitsi they would check the contact header and then go and look in their connection pool for a socket that already matched the address. If a connection exists they would go and reuse it. If it didn't they would create a new one. So every time we would waltz in with different addresses in Via and Contact, servers tried to connect to us on these addresses, and every time firewalls sitting in front of the clients would kill these connection attempts.

So we changed it and I do believe it makes more sense that way.

It is probably worth mentioning that this doesn't directly contradict RFC3261. If you are actually able to connect to our IP then we do want you to reuse the tuple from our contact header. We just don't want you to go and create a new connection. Why would you anyway?

    Here Viasays "send the responses to my_ip:18372" and Contactsays
    "send new requests (INVITE, NOTIFY, etc.), establishing a new TCP
    session,

The last part of the above sentence is where I disagree. Why would you go and insist on setting up a new TCP session? Yes, 3261 does not outright prohibit it but it pretty actively tries to encourage connection reuse. There is certainly not requirement that actually requires "establishing a new TCP session".

To sum things up: things must work with the shape Jitsi's messages currently come in. Not only is this not wrong but if they didn't work that would basically mean that all Internet hosted SIP providers would break.

Cheers,
Emil

···

On 16.12.15 г. 13:32, Anatoli wrote:

--
https://jitsi.org


#5

Emil,

Thanks for so detailed explanation.

I can't agree with the part that the described behavior "doesn't directly contradict RFC3261" as it states that Contact header field should be used for future requests (new connections) and Via header for the answer to the current request (on the same connection). Actually this is what was also described as the correct SIP implementation in the PJSIP and Asterisk dev mailinglists (links in the original message). Also the RFC states on page 143 that "[the client] MUST be prepared to receive incoming connections on any address and port that would be selected by a server based on the procedures ..."

I do agree that new connections are not strictly required and the same connection may be reused for everything under a typical usage. The problem is that it's not always possible to reuse a connection (connection errors, plugins not sharing the open socket, manual notifications (i.e. from a CLI or by scripts), etc. etc.) and some PBX servers (including Asterisk and PJSIP, its new default SIP stack) have some issues with that.

It looks like the current behavior in Jitsi (and some other clients) is a sort of a workaround for solving connectivity issues for NATed and firewalled connections to improperly implemented SIP servers: when reusing a connection the server should use the same socket and not look for details of the existing connection in the Contact field – at most Via field carries this information, but the RFC 5626 defines additional ways of identifying the "flow" without breaking compatibility with the original SIP RFC.

With respect to "why a change is now being considered" – actually, there are a lot of issues reported with this not-according-to-the-RFC behavior: just at the Asterisk issues tracker there are more than 5 related bug reports filled over the last couple of years with the final conclusion that it's not an Asterisk problem but of the clients.

At the same time, IMO, in general TCP is not so widely used for SIP (and the issues arise only with TCP connections as UDP has no problems of receiving "new" connections on the outgoing port) and the people who faced this issue decided it was way too complex to pursue a definitive, purist (RFC-compliant) solution or decided it was not worth the effort and switched back to UDP/implemented some workaround/adjusted the requirements.

Also PJSIP is a relatively new (now default) SIP stack for Asterisk (with some parts implemented from scratch) and it has some considerable differences with the old (embedded in the channel driver) SIP stack. I don't have the statistics, though I do believe its rate of adoption is quite low yet, but it's the Asterisk's future (http://blogs.digium.com/2013/11/20/asterisk-12-part-iv-sip-stack-future/).

Now knowing better the reason behind the current behavior, I believe there could be an option to choose the desired behavior. It would default to the current way of handling connections in order to maintain interoperability with the existing deployments, and provide a possibility to switch to the original scheme of specifying the listening port in the Contact field according to the RFC.

What do you think?

Regards,

Anatoli

···

-----Original Message-----
From: users [mailto:users-bounces@jitsi.org] On Behalf Of Emil Ivov
Sent: Wednesday, December 16, 2015 00:57
To: Jitsi Users
Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP connections

Hey folks,

This is a tricky topic. I have a lot of thoughts written below but my

short answer is that things are currently implemented the right-est

possible way in Jitsi ... considering the broken Internet we live in :).

The part that surprises me is that Asterisk has been working in a

compatible for for the past 15 years so I am curious why a change is now

being considered.

Here is some more thoughts about this:

The whole idea in 3261 about how clients should send their connection

tuples over signalling is inherently broken in today's internet. It may

make some amount of sense for server-to-server deployments. It could

also work for intra-LAN/VPN communication but it is widely known to be

broken for all other scenarios.

SIP outbound (RFC 5626) tries to solve this and it describes the problem

the following way:

    However, in a large number

    of real deployments, many practical considerations, such as the

   existence of firewalls and Network Address Translators (NATs) or the

    use of TLS with server-provided certificates, prevent servers from

    connecting to User Agents in this way.

For years now the send-responses-to-via-and-requests-to-contact parts of

3261 have been ignored by SIP services serving clients connecting from

the Internet. Every major SIP service out there, Twilio, OVH, ippi.com,

iptel.org ..., all of them more or less ignore Contact and Via addresses

and and reuse the connections they received from the client.

SIP wouldn't be working over the Internet if they weren't. This is why

RFC5265 was written.

More inline:

On 16.12.15 г. 13:32, Anatoli wrote:

Ingo,

Thanks for your reply. There certainly may be situations where a PBX and

an endpoint won't have a direct connection and there are (sometimes

complex) workarounds for this scenario.

We are not just talking about some cases here. Except for intraLAN

connections the IP address and port that come with SIP requests would

never work because of the reasons pointed above. Not even for public IPs.

Nevertheless there are a lot of cases where they do have a direct

connection (LAN, VPN, etc.). And in these situations, an incorrectly

formed Contactheader impedes a correct functioning of the SIP

notification mechanism.

Pooling connections and reusing sockets works just fine for these cases.

And according to the RFC 3261 (SIP: Session Initiation Protocol,

<https://www.ietf.org/rfc/rfc3261.txt> https://www.ietf.org/rfc/rfc3261.txt, 6th paragraph on page 12),

"/Contact [header] contains a SIP or SIPS URI that represents a direct

route to contact [an endpoint]/".

A fix for this issue is simple: when preparing the Contactheader, a

client just has to specify the listening port for the connection type in

use instead of an outgoing port.

I can assure you that nothing in there is simple :).

This is actually exactly what we were doing about 8 years ago and we

explicitly changed it. The reason back then was that when servers needed

to send requests back to Jitsi they would check the contact header and

then go and look in their connection pool for a socket that already

matched the address. If a connection exists they would go and reuse it.

If it didn't they would create a new one. So every time we would waltz

in with different addresses in Via and Contact, servers tried to connect

to us on these addresses, and every time firewalls sitting in front of

the clients would kill these connection attempts.

So we changed it and I do believe it makes more sense that way.

It is probably worth mentioning that this doesn't directly contradict

RFC3261. If you are actually able to connect to our IP then we do want

you to reuse the tuple from our contact header. We just don't want you

to go and create a new connection. Why would you anyway?

    Here Viasays "send the responses to my_ip:18372" and Contactsays

    "send new requests (INVITE, NOTIFY, etc.), establishing a new TCP

    session,

The last part of the above sentence is where I disagree. Why would you

go and insist on setting up a new TCP session? Yes, 3261 does not

outright prohibit it but it pretty actively tries to encourage

connection reuse. There is certainly not requirement that actually

requires "establishing a new TCP session".

To sum things up: things must work with the shape Jitsi's messages

currently come in. Not only is this not wrong but if they didn't work

that would basically mean that all Internet hosted SIP providers would

break.

Cheers,

Emil

--

<https://jitsi.org> https://jitsi.org

_______________________________________________

users mailing list

<mailto:users@jitsi.org> users@jitsi.org

Unsubscribe instructions and other list options:

<http://lists.jitsi.org/mailman/listinfo/users> http://lists.jitsi.org/mailman/listinfo/users


#6

Hey Anatoli,

Emil,

Thanks for so detailed explanation.

I can't agree with the part that the described behavior "doesn't
directly contradict RFC3261" as it states that Contactheader field
should be used for future requests (new connections) and Viaheader for
the answer to the current request (on the same connection).

Indeed it does. I am not arguing with that. The part that I have a problem with is your assertion that sending new requests absolutely requires a new TCP connection.

Actually
this is what was also described as the correct SIP implementation in the
PJSIP and Asterisk dev mailinglists (links in the original message).
Also the RFC states on page 143 that "[the client]MUST be prepared to
receive incoming connections on any address and port that would be
selected by a server based on the procedures ..."

True and that part is broken by the existence of NATs and firewalls on the Internet, so even if we did support new incoming TCP connections you would still be unable to send us messages there.

Because ... this part of the RFC is broken! :slight_smile:

I do agree that new connections are not strictly required and the same
connection may be reused for everything under a typical usage. The
problem is that it's not always possible to reuse a connection
(connection errors, plugins not sharing the open socket, manual
notifications (i.e. from a CLI or by scripts), etc. etc.) and some PBX
servers (including Asterisk and PJSIP, its new default SIP stack) have
some issues with that.

Also true, however allowing incoming TCP connection would only solve a tiny percentage of cases. The correct behaviour in case of a broken TCP connection would be for the client to re-register and for the server to retry the request at that point, unless the corresponding transaction has already expired.

Asterisk must do that or else it doesn't work on the Internet. If it does that then it works with Jitsi in it's current state. It's as simple as that.

I know that this is not the behaviour 3261 describes for this situation but that is because ... this part of the RFC is broken! :slight_smile:

It looks like the current behavior in Jitsi (and some other clients) is
a sort of a workaround for solving connectivity issues for NATed and
firewalled connections to improperly implemented SIP servers:

Don't you think your use of "Improperly" is a bit harsh here given that these are the only servers that worked over the Internet for a long period of time?

This was clearly a 3261 mistake that implementers had to fix themselves and they did.

In a recent chat I had with Alan Johnston he himself mentioned that 3261's choice to ignore NATs was probably one of his biggest regrets from the days of editing the RFC.

when
reusing a connection the server should use the same socket and not look
for details of the existing connection in the Contactfield – at most
Viafield carries this information, but the RFC 5626 defines additional
ways of identifying the "flow" without breaking compatibility with the
original SIP RFC.

Correct. 5626 was a very late attempt to fix the broken-ness of 3261 in that aspect. As you have seen yourself, it wasn't super successful in terms of adoption. I only brought it up to point out that the problem with 3261 is recognized by the IETF.

With respect to "why a change is now being considered" – actually, there
are a lot of issues reported with this not-according-to-the-RFC
behavior: just at the Asterisk issues tracker there are more than 5
related bug reports filled over the last couple of years with the final
conclusion that it's not an Asterisk problem but of the clients.

You do realise that using the "according-to-the-RFC" approach simply breaks Asterisk in "over the Internet" scenarios, right?

How could anyone possibly push in that direction?

An RFC does not represent an absolute universal truth. It's a document written by people in order to facilitate a purpose. If it prevents you from achieving that very same purpose then there is no reason to stick with it ...

At the same time, IMO, in general TCP is not so widely used for SIP

Another one of SIP's huge mistakes.

(and
the issues arise only with TCP connections as UDP has no problems of
receiving "new" connections on the outgoing port)

Except that there too, if you use that port you are breaking over-the-internet deployments.

and the people who
faced this issue decided it was way too complex to pursue a definitive,
purist (RFC-compliant) solution or decided it was not worth the effort
and switched back to UDP/implemented some workaround/adjusted the
requirements.

Also PJSIP is a relatively new (now default) SIP stack for Asterisk
(with some parts implemented from scratch) and it has some considerable
differences with the old (embedded in the channel driver) SIP stack. I
don't have the statistics, though I do believe its rate of adoption is
quite low yet, but it's the Asterisk's future
(http://blogs.digium.com/2013/11/20/asterisk-12-part-iv-sip-stack-future/).

I was aware of the big plans for that version, but I didn't know it wasn't supposed to work over the Internet any more.

If that is the direction that Asterisk sticks with then I guess FreeSWITCH is about to double in popularity.

Now knowing better the reason behind the current behavior, I believe
there could be an option to choose the desired behavior. It would
default to the current way of handling connections in order to maintain
interoperability with the existing deployments, and provide a
possibility to switch to the original scheme of specifying the listening
port in the Contactfield according to the RFC.

What do you think?

All of what I said above. I don't think someone's stubbornness of implementing an RFC aspect that is known to be broken is reason enough for further complicating SIP's already excessively convoluted settings.

Cheers,
Emil

···

On 16.12.15 г. 17:38, Anatoli wrote:

-----Original Message-----
From: users [mailto:users-bounces@jitsi.org] On Behalf Of Emil Ivov
Sent: Wednesday, December 16, 2015 00:57
To: Jitsi Users
Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP
connections

Hey folks,

This is a tricky topic. I have a lot of thoughts written below but my

short answer is that things are currently implemented the right-est

possible way in Jitsi ... considering the broken Internet we live in :).

The part that surprises me is that Asterisk has been working in a

compatible for for the past 15 years so I am curious why a change is now

being considered.

Here is some more thoughts about this:

The whole idea in 3261 about how clients should send their connection

tuples over signalling is inherently broken in today's internet. It may

make some amount of sense for server-to-server deployments. It could

also work for intra-LAN/VPN communication but it is widely known to be

broken for all other scenarios.

SIP outbound (RFC 5626) tries to solve this and it describes the problem

the following way:

     However, in a large number

     of real deployments, many practical considerations, such as the

    existence of firewalls and Network Address Translators (NATs) or the

     use of TLS with server-provided certificates, prevent servers from

     connecting to User Agents in this way.

For years now the send-responses-to-via-and-requests-to-contact parts of

3261 have been ignored by SIP services serving clients connecting from

the Internet. Every major SIP service out there, Twilio, OVH, ippi.com,

iptel.org ..., all of them more or less ignore Contact and Via addresses

and and reuse the connections they received from the client.

SIP wouldn't be working over the Internet if they weren't. This is why

RFC5265 was written.

More inline:

On 16.12.15 г. 13:32, Anatoli wrote:

> Ingo,

>

> Thanks for your reply. There certainly may be situations where a PBX and

> an endpoint won't have a direct connection and there are (sometimes

> complex) workarounds for this scenario.

We are not just talking about some cases here. Except for intraLAN

connections the IP address and port that come with SIP requests would

never work because of the reasons pointed above. Not even for public IPs.

> Nevertheless there are a lot of cases where they do have a direct

> connection (LAN, VPN, etc.). And in these situations, an incorrectly

> formed Contactheader impedes a correct functioning of the SIP

> notification mechanism.

Pooling connections and reusing sockets works just fine for these cases.

> And according to the RFC 3261 (SIP: Session Initiation Protocol,

> https://www.ietf.org/rfc/rfc3261.txt, 6th paragraph on page 12),

> "/Contact [header] contains a SIP or SIPS URI that represents a direct

> route to contact [an endpoint]/".

>

> A fix for this issue is simple: when preparing the Contactheader, a

> client just has to specify the listening port for the connection type in

> use instead of an outgoing port.

I can assure you that nothing in there is simple :).

This is actually exactly what we were doing about 8 years ago and we

explicitly changed it. The reason back then was that when servers needed

to send requests back to Jitsi they would check the contact header and

then go and look in their connection pool for a socket that already

matched the address. If a connection exists they would go and reuse it.

If it didn't they would create a new one. So every time we would waltz

in with different addresses in Via and Contact, servers tried to connect

to us on these addresses, and every time firewalls sitting in front of

the clients would kill these connection attempts.

So we changed it and I do believe it makes more sense that way.

It is probably worth mentioning that this doesn't directly contradict

RFC3261. If you are actually able to connect to our IP then we do want

you to reuse the tuple from our contact header. We just don't want you

to go and create a new connection. Why would you anyway?

> Here Viasays "send the responses to my_ip:18372" and Contactsays

> "send new requests (INVITE, NOTIFY, etc.), establishing a new TCP

> session,

The last part of the above sentence is where I disagree. Why would you

go and insist on setting up a new TCP session? Yes, 3261 does not

outright prohibit it but it pretty actively tries to encourage

connection reuse. There is certainly not requirement that actually

requires "establishing a new TCP session".

To sum things up: things must work with the shape Jitsi's messages

currently come in. Not only is this not wrong but if they didn't work

that would basically mean that all Internet hosted SIP providers would

break.

Cheers,

Emil

--

https://jitsi.org

_______________________________________________

users mailing list

users@jitsi.org <mailto:users@jitsi.org>

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users

--
https://jitsi.org


#7

Emil,

OK, I see your point though I disagree that the standards should not be followed whenever possible.

Also I understand that there are a number of huge public VoIP providers that require NAT and firewall traversal capabilities over the internet, but there are also use cases for thousands of smaller inside-company deployments that don't necessary have to traverse NAT or firewalls (or they have them configured accordingly). For these use cases (also our situation) it's more desirable to have the RFC-compliant behavior for interoperability with other systems (and own developments) inside the organization.

That's why I believe there is a rationale behind adding the previously described option to define the behavior with respect to the Contact field. If you strongly disagree with that, could you please at least point me to the location of the code responsible for the construction of the Contact field so I can build a version of Jitsi that suits our needs?

Thanks,

Anatoli

···

-----Original Message-----
From: users [mailto:users-bounces@jitsi.org] On Behalf Of Emil Ivov
Sent: Wednesday, December 16, 2015 04:58
To: Jitsi Users
Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP connections

Hey Anatoli,

On 16.12.15 г. 17:38, Anatoli wrote:

Emil,

Thanks for so detailed explanation.

I can't agree with the part that the described behavior "doesn't

directly contradict RFC3261" as it states that Contactheader field

should be used for future requests (new connections) and Viaheader for

the answer to the current request (on the same connection).

Indeed it does. I am not arguing with that. The part that I have a

problem with is your assertion that sending new requests absolutely

requires a new TCP connection.

Actually

this is what was also described as the correct SIP implementation in the

PJSIP and Asterisk dev mailinglists (links in the original message).

Also the RFC states on page 143 that "[the client]MUST be prepared to

receive incoming connections on any address and port that would be

selected by a server based on the procedures ..."

True and that part is broken by the existence of NATs and firewalls on

the Internet, so even if we did support new incoming TCP connections you

would still be unable to send us messages there.

Because ... this part of the RFC is broken! :slight_smile:

I do agree that new connections are not strictly required and the same

connection may be reused for everything under a typical usage. The

problem is that it's not always possible to reuse a connection

(connection errors, plugins not sharing the open socket, manual

notifications (i.e. from a CLI or by scripts), etc. etc.) and some PBX

servers (including Asterisk and PJSIP, its new default SIP stack) have

some issues with that.

Also true, however allowing incoming TCP connection would only solve a

tiny percentage of cases. The correct behaviour in case of a broken TCP

connection would be for the client to re-register and for the server to

retry the request at that point, unless the corresponding transaction

has already expired.

Asterisk must do that or else it doesn't work on the Internet. If it

does that then it works with Jitsi in it's current state. It's as simple

as that.

I know that this is not the behaviour 3261 describes for this situation

but that is because ... this part of the RFC is broken! :slight_smile:

It looks like the current behavior in Jitsi (and some other clients) is

a sort of a workaround for solving connectivity issues for NATed and

firewalled connections to improperly implemented SIP servers:

Don't you think your use of "Improperly" is a bit harsh here given that

these are the only servers that worked over the Internet for a long

period of time?

This was clearly a 3261 mistake that implementers had to fix themselves

and they did.

In a recent chat I had with Alan Johnston he himself mentioned that

3261's choice to ignore NATs was probably one of his biggest regrets

from the days of editing the RFC.

when

reusing a connection the server should use the same socket and not look

for details of the existing connection in the Contactfield – at most

Viafield carries this information, but the RFC 5626 defines additional

ways of identifying the "flow" without breaking compatibility with the

original SIP RFC.

Correct. 5626 was a very late attempt to fix the broken-ness of 3261 in

that aspect. As you have seen yourself, it wasn't super successful in

terms of adoption. I only brought it up to point out that the problem

with 3261 is recognized by the IETF.

With respect to "why a change is now being considered" – actually, there

are a lot of issues reported with this not-according-to-the-RFC

behavior: just at the Asterisk issues tracker there are more than 5

related bug reports filled over the last couple of years with the final

conclusion that it's not an Asterisk problem but of the clients.

You do realise that using the "according-to-the-RFC" approach simply

breaks Asterisk in "over the Internet" scenarios, right?

How could anyone possibly push in that direction?

An RFC does not represent an absolute universal truth. It's a document

written by people in order to facilitate a purpose. If it prevents you

from achieving that very same purpose then there is no reason to stick

with it ...

At the same time, IMO, in general TCP is not so widely used for SIP

Another one of SIP's huge mistakes.

(and

the issues arise only with TCP connections as UDP has no problems of

receiving "new" connections on the outgoing port)

Except that there too, if you use that port you are breaking

over-the-internet deployments.

and the people who

faced this issue decided it was way too complex to pursue a definitive,

purist (RFC-compliant) solution or decided it was not worth the effort

and switched back to UDP/implemented some workaround/adjusted the

requirements.

Also PJSIP is a relatively new (now default) SIP stack for Asterisk

(with some parts implemented from scratch) and it has some considerable

differences with the old (embedded in the channel driver) SIP stack. I

don't have the statistics, though I do believe its rate of adoption is

quite low yet, but it's the Asterisk's future

( <http://blogs.digium.com/2013/11/20/asterisk-12-part-iv-sip-stack-future/> http://blogs.digium.com/2013/11/20/asterisk-12-part-iv-sip-stack-future/).

I was aware of the big plans for that version, but I didn't know it

wasn't supposed to work over the Internet any more.

If that is the direction that Asterisk sticks with then I guess

FreeSWITCH is about to double in popularity.

Now knowing better the reason behind the current behavior, I believe

there could be an option to choose the desired behavior. It would

default to the current way of handling connections in order to maintain

interoperability with the existing deployments, and provide a

possibility to switch to the original scheme of specifying the listening

port in the Contactfield according to the RFC.

What do you think?

All of what I said above. I don't think someone's stubbornness of

implementing an RFC aspect that is known to be broken is reason enough

for further complicating SIP's already excessively convoluted settings.

Cheers,

Emil

-----Original Message-----

From: users [ <mailto:users-bounces@jitsi.org> mailto:users-bounces@jitsi.org] On Behalf Of Emil Ivov

Sent: Wednesday, December 16, 2015 00:57

To: Jitsi Users

Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP

connections

Hey folks,

This is a tricky topic. I have a lot of thoughts written below but my

short answer is that things are currently implemented the right-est

possible way in Jitsi ... considering the broken Internet we live in :).

The part that surprises me is that Asterisk has been working in a

compatible for for the past 15 years so I am curious why a change is now

being considered.

Here is some more thoughts about this:

The whole idea in 3261 about how clients should send their connection

tuples over signalling is inherently broken in today's internet. It may

make some amount of sense for server-to-server deployments. It could

also work for intra-LAN/VPN communication but it is widely known to be

broken for all other scenarios.

SIP outbound (RFC 5626) tries to solve this and it describes the problem

the following way:

     However, in a large number

     of real deployments, many practical considerations, such as the

    existence of firewalls and Network Address Translators (NATs) or the

     use of TLS with server-provided certificates, prevent servers from

     connecting to User Agents in this way.

For years now the send-responses-to-via-and-requests-to-contact parts of

3261 have been ignored by SIP services serving clients connecting from

the Internet. Every major SIP service out there, Twilio, OVH, ippi.com,

iptel.org ..., all of them more or less ignore Contact and Via addresses

and and reuse the connections they received from the client.

SIP wouldn't be working over the Internet if they weren't. This is why

RFC5265 was written.

More inline:

On 16.12.15 г. 13:32, Anatoli wrote:

> Ingo,

>

> Thanks for your reply. There certainly may be situations where a PBX and

> an endpoint won't have a direct connection and there are (sometimes

> complex) workarounds for this scenario.

We are not just talking about some cases here. Except for intraLAN

connections the IP address and port that come with SIP requests would

never work because of the reasons pointed above. Not even for public IPs.

> Nevertheless there are a lot of cases where they do have a direct

> connection (LAN, VPN, etc.). And in these situations, an incorrectly

> formed Contactheader impedes a correct functioning of the SIP

> notification mechanism.

Pooling connections and reusing sockets works just fine for these cases.

> And according to the RFC 3261 (SIP: Session Initiation Protocol,

> <https://www.ietf.org/rfc/rfc3261.txt> https://www.ietf.org/rfc/rfc3261.txt, 6th paragraph on page 12),

> "/Contact [header] contains a SIP or SIPS URI that represents a direct

> route to contact [an endpoint]/".

>

> A fix for this issue is simple: when preparing the Contactheader, a

> client just has to specify the listening port for the connection type in

> use instead of an outgoing port.

I can assure you that nothing in there is simple :).

This is actually exactly what we were doing about 8 years ago and we

explicitly changed it. The reason back then was that when servers needed

to send requests back to Jitsi they would check the contact header and

then go and look in their connection pool for a socket that already

matched the address. If a connection exists they would go and reuse it.

If it didn't they would create a new one. So every time we would waltz

in with different addresses in Via and Contact, servers tried to connect

to us on these addresses, and every time firewalls sitting in front of

the clients would kill these connection attempts.

So we changed it and I do believe it makes more sense that way.

It is probably worth mentioning that this doesn't directly contradict

RFC3261. If you are actually able to connect to our IP then we do want

you to reuse the tuple from our contact header. We just don't want you

to go and create a new connection. Why would you anyway?

> Here Viasays "send the responses to my_ip:18372" and Contactsays

> "send new requests (INVITE, NOTIFY, etc.), establishing a new TCP

> session,

The last part of the above sentence is where I disagree. Why would you

go and insist on setting up a new TCP session? Yes, 3261 does not

outright prohibit it but it pretty actively tries to encourage

connection reuse. There is certainly not requirement that actually

requires "establishing a new TCP session".

To sum things up: things must work with the shape Jitsi's messages

currently come in. Not only is this not wrong but if they didn't work

that would basically mean that all Internet hosted SIP providers would

break.

Cheers,

Emil

--

<https://jitsi.org> https://jitsi.org

_______________________________________________

users mailing list

<mailto:users@jitsi.org> users@jitsi.org < <mailto:users@jitsi.org> mailto:users@jitsi.org>

Unsubscribe instructions and other list options:

<http://lists.jitsi.org/mailman/listinfo/users> http://lists.jitsi.org/mailman/listinfo/users

_______________________________________________

users mailing list

<mailto:users@jitsi.org> users@jitsi.org

Unsubscribe instructions and other list options:

<http://lists.jitsi.org/mailman/listinfo/users> http://lists.jitsi.org/mailman/listinfo/users

--

<https://jitsi.org> https://jitsi.org

_______________________________________________

users mailing list

<mailto:users@jitsi.org> users@jitsi.org

Unsubscribe instructions and other list options:

<http://lists.jitsi.org/mailman/listinfo/users> http://lists.jitsi.org/mailman/listinfo/users


#8

Inline

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

Emil,

OK, I see your point though I disagree that the standards should not be followed whenever possible.

Also I understand that there are a number of huge public VoIP providers that require NAT and firewall traversal capabilities over the internet, but there are also use cases for thousands of smaller inside-company deployments that don't necessary have to traverse NAT or firewalls (or they have them configured accordingly). For these use cases (also our situation) it's more desirable to have the RFC-compliant behavior for interoperability with other systems (and own developments) inside the organization.

I'm not sure what kind if network you're running, but it somehow implies to me that you have no host firewalls. Which contradicts nowadays 'assume breach' principle.

That's why I believe there is a rationale behind adding the previously described option to define the behavior with respect to the Contact field. If you strongly disagree with that, could you please at least point me to the location of the code responsible for the construction of the Contact field so I can build a version of Jitsi that suits our needs?

I'm on my mobile, so not entirely sure but have a look ar SdpUtils and CallPeerSipImpl. But just changing the header probably won't do you much good without making the SIP stack actually listen to the dynamic ports.

Thanks,
Anatoli

Ingo

···

On 17.12.2015, at 06:45, Anatoli <me@anatoli.ws> wrote:

-----Original Message-----
From: users [mailto:users-bounces@jitsi.org] On Behalf Of Emil Ivov
Sent: Wednesday, December 16, 2015 04:58
To: Jitsi Users
Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP connections

Hey Anatoli,

On 16.12.15 г. 17:38, Anatoli wrote:
> Emil,
>
> Thanks for so detailed explanation.
>
> I can't agree with the part that the described behavior "doesn't
> directly contradict RFC3261" as it states that Contactheader field
> should be used for future requests (new connections) and Viaheader for
> the answer to the current request (on the same connection).

Indeed it does. I am not arguing with that. The part that I have a
problem with is your assertion that sending new requests absolutely
requires a new TCP connection.

> Actually
> this is what was also described as the correct SIP implementation in the
> PJSIP and Asterisk dev mailinglists (links in the original message).
> Also the RFC states on page 143 that "[the client]MUST be prepared to
> receive incoming connections on any address and port that would be
> selected by a server based on the procedures ..."

True and that part is broken by the existence of NATs and firewalls on
the Internet, so even if we did support new incoming TCP connections you
would still be unable to send us messages there.

Because ... this part of the RFC is broken! :slight_smile:

> I do agree that new connections are not strictly required and the same
> connection may be reused for everything under a typical usage. The
> problem is that it's not always possible to reuse a connection
> (connection errors, plugins not sharing the open socket, manual
> notifications (i.e. from a CLI or by scripts), etc. etc.) and some PBX
> servers (including Asterisk and PJSIP, its new default SIP stack) have
> some issues with that.

Also true, however allowing incoming TCP connection would only solve a
tiny percentage of cases. The correct behaviour in case of a broken TCP
connection would be for the client to re-register and for the server to
retry the request at that point, unless the corresponding transaction
has already expired.

Asterisk must do that or else it doesn't work on the Internet. If it
does that then it works with Jitsi in it's current state. It's as simple
as that.

I know that this is not the behaviour 3261 describes for this situation
but that is because ... this part of the RFC is broken! :slight_smile:

> It looks like the current behavior in Jitsi (and some other clients) is
> a sort of a workaround for solving connectivity issues for NATed and
> firewalled connections to improperly implemented SIP servers:

Don't you think your use of "Improperly" is a bit harsh here given that
these are the only servers that worked over the Internet for a long
period of time?

This was clearly a 3261 mistake that implementers had to fix themselves
and they did.

In a recent chat I had with Alan Johnston he himself mentioned that
3261's choice to ignore NATs was probably one of his biggest regrets
from the days of editing the RFC.

> when
> reusing a connection the server should use the same socket and not look
> for details of the existing connection in the Contactfield – at most
> Viafield carries this information, but the RFC 5626 defines additional
> ways of identifying the "flow" without breaking compatibility with the
> original SIP RFC.

Correct. 5626 was a very late attempt to fix the broken-ness of 3261 in
that aspect. As you have seen yourself, it wasn't super successful in
terms of adoption. I only brought it up to point out that the problem
with 3261 is recognized by the IETF.

> With respect to "why a change is now being considered" – actually, there
> are a lot of issues reported with this not-according-to-the-RFC
> behavior: just at the Asterisk issues tracker there are more than 5
> related bug reports filled over the last couple of years with the final
> conclusion that it's not an Asterisk problem but of the clients.

You do realise that using the "according-to-the-RFC" approach simply
breaks Asterisk in "over the Internet" scenarios, right?

How could anyone possibly push in that direction?

An RFC does not represent an absolute universal truth. It's a document
written by people in order to facilitate a purpose. If it prevents you
from achieving that very same purpose then there is no reason to stick
with it ...

> At the same time, IMO, in general TCP is not so widely used for SIP

Another one of SIP's huge mistakes.

> (and
> the issues arise only with TCP connections as UDP has no problems of
> receiving "new" connections on the outgoing port)

Except that there too, if you use that port you are breaking
over-the-internet deployments.

> and the people who
> faced this issue decided it was way too complex to pursue a definitive,
> purist (RFC-compliant) solution or decided it was not worth the effort
> and switched back to UDP/implemented some workaround/adjusted the
> requirements.
>
> Also PJSIP is a relatively new (now default) SIP stack for Asterisk
> (with some parts implemented from scratch) and it has some considerable
> differences with the old (embedded in the channel driver) SIP stack. I
> don't have the statistics, though I do believe its rate of adoption is
> quite low yet, but it's the Asterisk's future
> (http://blogs.digium.com/2013/11/20/asterisk-12-part-iv-sip-stack-future/).

I was aware of the big plans for that version, but I didn't know it
wasn't supposed to work over the Internet any more.

If that is the direction that Asterisk sticks with then I guess
FreeSWITCH is about to double in popularity.

> Now knowing better the reason behind the current behavior, I believe
> there could be an option to choose the desired behavior. It would
> default to the current way of handling connections in order to maintain
> interoperability with the existing deployments, and provide a
> possibility to switch to the original scheme of specifying the listening
> port in the Contactfield according to the RFC.
>
> What do you think?

All of what I said above. I don't think someone's stubbornness of
implementing an RFC aspect that is known to be broken is reason enough
for further complicating SIP's already excessively convoluted settings.

Cheers,
Emil

> -----Original Message-----
> From: users [mailto:users-bounces@jitsi.org] On Behalf Of Emil Ivov
> Sent: Wednesday, December 16, 2015 00:57
> To: Jitsi Users
> Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP
> connections
>
> Hey folks,
>
> This is a tricky topic. I have a lot of thoughts written below but my
>
> short answer is that things are currently implemented the right-est
>
> possible way in Jitsi ... considering the broken Internet we live in :).
>
> The part that surprises me is that Asterisk has been working in a
>
> compatible for for the past 15 years so I am curious why a change is now
>
> being considered.
>
> Here is some more thoughts about this:
>
> The whole idea in 3261 about how clients should send their connection
>
> tuples over signalling is inherently broken in today's internet. It may
>
> make some amount of sense for server-to-server deployments. It could
>
> also work for intra-LAN/VPN communication but it is widely known to be
>
> broken for all other scenarios.
>
> SIP outbound (RFC 5626) tries to solve this and it describes the problem
>
> the following way:
>
> However, in a large number
>
> of real deployments, many practical considerations, such as the
>
> existence of firewalls and Network Address Translators (NATs) or the
>
> use of TLS with server-provided certificates, prevent servers from
>
> connecting to User Agents in this way.
>
> For years now the send-responses-to-via-and-requests-to-contact parts of
>
> 3261 have been ignored by SIP services serving clients connecting from
>
> the Internet. Every major SIP service out there, Twilio, OVH, ippi.com,
>
> iptel.org ..., all of them more or less ignore Contact and Via addresses
>
> and and reuse the connections they received from the client.
>
> SIP wouldn't be working over the Internet if they weren't. This is why
>
> RFC5265 was written.
>
> More inline:
>
> On 16.12.15 г. 13:32, Anatoli wrote:
>
> > Ingo,
>
> >
>
> > Thanks for your reply. There certainly may be situations where a PBX and
>
> > an endpoint won't have a direct connection and there are (sometimes
>
> > complex) workarounds for this scenario.
>
> We are not just talking about some cases here. Except for intraLAN
>
> connections the IP address and port that come with SIP requests would
>
> never work because of the reasons pointed above. Not even for public IPs.
>
> > Nevertheless there are a lot of cases where they do have a direct
>
> > connection (LAN, VPN, etc.). And in these situations, an incorrectly
>
> > formed Contactheader impedes a correct functioning of the SIP
>
> > notification mechanism.
>
> Pooling connections and reusing sockets works just fine for these cases.
>
> > And according to the RFC 3261 (SIP: Session Initiation Protocol,
>
> > https://www.ietf.org/rfc/rfc3261.txt, 6th paragraph on page 12),
>
> > "/Contact [header] contains a SIP or SIPS URI that represents a direct
>
> > route to contact [an endpoint]/".
>
> >
>
> > A fix for this issue is simple: when preparing the Contactheader, a
>
> > client just has to specify the listening port for the connection type in
>
> > use instead of an outgoing port.
>
> I can assure you that nothing in there is simple :).
>
> This is actually exactly what we were doing about 8 years ago and we
>
> explicitly changed it. The reason back then was that when servers needed
>
> to send requests back to Jitsi they would check the contact header and
>
> then go and look in their connection pool for a socket that already
>
> matched the address. If a connection exists they would go and reuse it.
>
> If it didn't they would create a new one. So every time we would waltz
>
> in with different addresses in Via and Contact, servers tried to connect
>
> to us on these addresses, and every time firewalls sitting in front of
>
> the clients would kill these connection attempts.
>
> So we changed it and I do believe it makes more sense that way.
>
> It is probably worth mentioning that this doesn't directly contradict
>
> RFC3261. If you are actually able to connect to our IP then we do want
>
> you to reuse the tuple from our contact header. We just don't want you
>
> to go and create a new connection. Why would you anyway?
>
> > Here Viasays "send the responses to my_ip:18372" and Contactsays
>
> > "send new requests (INVITE, NOTIFY, etc.), establishing a new TCP
>
> > session,
>
> The last part of the above sentence is where I disagree. Why would you
>
> go and insist on setting up a new TCP session? Yes, 3261 does not
>
> outright prohibit it but it pretty actively tries to encourage
>
> connection reuse. There is certainly not requirement that actually
>
> requires "establishing a new TCP session".
>
> To sum things up: things must work with the shape Jitsi's messages
>
> currently come in. Not only is this not wrong but if they didn't work
>
> that would basically mean that all Internet hosted SIP providers would
>
> break.
>
> Cheers,
>
> Emil
>
> --
>
> https://jitsi.org
>
> _______________________________________________
>
> users mailing list
>
> users@jitsi.org <mailto:users@jitsi.org>
>
> Unsubscribe instructions and other list options:
>
> http://lists.jitsi.org/mailman/listinfo/users
>
>
>
> _______________________________________________
> users mailing list
> users@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/users
>

--
https://jitsi.org

_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users


#9

Emil,

OK, I see your point though I disagree that the standards should not be
followed whenever possible.

I really said exactly the opposite. In this case it is simply not
..possible.

Also I understand that there are a number of huge public VoIP providers
that require NAT and firewall traversal capabilities over the internet, but
there are also use cases for thousands of smaller inside-company
deployments that don't necessary have to traverse NAT or firewalls

And implementing the behaviour that everyone has (including Asterisk for
the past 15 years) works just fine. Not to mention that reusing connections
is in no way a violation of the RFC so what we are arguing about here is
having Asterisk choose between two forms of standard behaviour one of which
works for everyone and the other not.

(or they have them configured accordingly). For these use cases (also our

situation) it's more desirable to have the RFC-compliant behavior for
interoperability with other systems (and own developments) inside the
organization.

That's why I believe there is a rationale behind adding the previously
described option to define the behavior with respect to the Contact field.
If you strongly disagree with that,

I do.

could you please at least point me to the location of the code responsible

for the construction of the Contact field so I can build a version of Jitsi
that suits our needs?

I believe Ingo just did.

Emil

···

On Thursday, 17 December 2015, Anatoli <me@anatoli.ws> wrote:

Thanks,

Anatoli

-----Original Message-----
From: users [mailto:users-bounces@jitsi.org
<javascript:_e(%7B%7D,'cvml','users-bounces@jitsi.org');>] On Behalf Of
Emil Ivov
Sent: Wednesday, December 16, 2015 04:58
To: Jitsi Users
Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP
connections

Hey Anatoli,

On 16.12.15 г. 17:38, Anatoli wrote:

> Emil,

>

> Thanks for so detailed explanation.

>

> I can't agree with the part that the described behavior "doesn't

> directly contradict RFC3261" as it states that Contactheader field

> should be used for future requests (new connections) and Viaheader for

> the answer to the current request (on the same connection).

Indeed it does. I am not arguing with that. The part that I have a

problem with is your assertion that sending new requests absolutely

requires a new TCP connection.

> Actually

> this is what was also described as the correct SIP implementation in the

> PJSIP and Asterisk dev mailinglists (links in the original message).

> Also the RFC states on page 143 that "[the client]MUST be prepared to

> receive incoming connections on any address and port that would be

> selected by a server based on the procedures ..."

True and that part is broken by the existence of NATs and firewalls on

the Internet, so even if we did support new incoming TCP connections you

would still be unable to send us messages there.

Because ... this part of the RFC is broken! :slight_smile:

> I do agree that new connections are not strictly required and the same

> connection may be reused for everything under a typical usage. The

> problem is that it's not always possible to reuse a connection

> (connection errors, plugins not sharing the open socket, manual

> notifications (i.e. from a CLI or by scripts), etc. etc.) and some PBX

> servers (including Asterisk and PJSIP, its new default SIP stack) have

> some issues with that.

Also true, however allowing incoming TCP connection would only solve a

tiny percentage of cases. The correct behaviour in case of a broken TCP

connection would be for the client to re-register and for the server to

retry the request at that point, unless the corresponding transaction

has already expired.

Asterisk must do that or else it doesn't work on the Internet. If it

does that then it works with Jitsi in it's current state. It's as simple

as that.

I know that this is not the behaviour 3261 describes for this situation

but that is because ... this part of the RFC is broken! :slight_smile:

> It looks like the current behavior in Jitsi (and some other clients) is

> a sort of a workaround for solving connectivity issues for NATed and

> firewalled connections to improperly implemented SIP servers:

Don't you think your use of "Improperly" is a bit harsh here given that

these are the only servers that worked over the Internet for a long

period of time?

This was clearly a 3261 mistake that implementers had to fix themselves

and they did.

In a recent chat I had with Alan Johnston he himself mentioned that

3261's choice to ignore NATs was probably one of his biggest regrets

from the days of editing the RFC.

> when

> reusing a connection the server should use the same socket and not look

> for details of the existing connection in the Contactfield – at most

> Viafield carries this information, but the RFC 5626 defines additional

> ways of identifying the "flow" without breaking compatibility with the

> original SIP RFC.

Correct. 5626 was a very late attempt to fix the broken-ness of 3261 in

that aspect. As you have seen yourself, it wasn't super successful in

terms of adoption. I only brought it up to point out that the problem

with 3261 is recognized by the IETF.

> With respect to "why a change is now being considered" – actually, there

> are a lot of issues reported with this not-according-to-the-RFC

> behavior: just at the Asterisk issues tracker there are more than 5

> related bug reports filled over the last couple of years with the final

> conclusion that it's not an Asterisk problem but of the clients.

You do realise that using the "according-to-the-RFC" approach simply

breaks Asterisk in "over the Internet" scenarios, right?

How could anyone possibly push in that direction?

An RFC does not represent an absolute universal truth. It's a document

written by people in order to facilitate a purpose. If it prevents you

from achieving that very same purpose then there is no reason to stick

with it ...

> At the same time, IMO, in general TCP is not so widely used for SIP

Another one of SIP's huge mistakes.

> (and

> the issues arise only with TCP connections as UDP has no problems of

> receiving "new" connections on the outgoing port)

Except that there too, if you use that port you are breaking

over-the-internet deployments.

> and the people who

> faced this issue decided it was way too complex to pursue a definitive,

> purist (RFC-compliant) solution or decided it was not worth the effort

> and switched back to UDP/implemented some workaround/adjusted the

> requirements.

>

> Also PJSIP is a relatively new (now default) SIP stack for Asterisk

> (with some parts implemented from scratch) and it has some considerable

> differences with the old (embedded in the channel driver) SIP stack. I

> don't have the statistics, though I do believe its rate of adoption is

> quite low yet, but it's the Asterisk's future

> (
http://blogs.digium.com/2013/11/20/asterisk-12-part-iv-sip-stack-future/).

I was aware of the big plans for that version, but I didn't know it

wasn't supposed to work over the Internet any more.

If that is the direction that Asterisk sticks with then I guess

FreeSWITCH is about to double in popularity.

> Now knowing better the reason behind the current behavior, I believe

> there could be an option to choose the desired behavior. It would

> default to the current way of handling connections in order to maintain

> interoperability with the existing deployments, and provide a

> possibility to switch to the original scheme of specifying the listening

> port in the Contactfield according to the RFC.

>

> What do you think?

All of what I said above. I don't think someone's stubbornness of

implementing an RFC aspect that is known to be broken is reason enough

for further complicating SIP's already excessively convoluted settings.

Cheers,

Emil

> -----Original Message-----

> From: users [mailto:users-bounces@jitsi.org
<javascript:_e(%7B%7D,'cvml','users-bounces@jitsi.org');>] On Behalf Of
Emil Ivov

> Sent: Wednesday, December 16, 2015 00:57

> To: Jitsi Users

> Subject: Re: [jitsi-users] Incorrect port in Contact header for TCP

> connections

>

> Hey folks,

>

> This is a tricky topic. I have a lot of thoughts written below but my

>

> short answer is that things are currently implemented the right-est

>

> possible way in Jitsi ... considering the broken Internet we live in :).

>

> The part that surprises me is that Asterisk has been working in a

>

> compatible for for the past 15 years so I am curious why a change is now

>

> being considered.

>

> Here is some more thoughts about this:

>

> The whole idea in 3261 about how clients should send their connection

>

> tuples over signalling is inherently broken in today's internet. It may

>

> make some amount of sense for server-to-server deployments. It could

>

> also work for intra-LAN/VPN communication but it is widely known to be

>

> broken for all other scenarios.

>

> SIP outbound (RFC 5626) tries to solve this and it describes the problem

>

> the following way:

>

> However, in a large number

>

> of real deployments, many practical considerations, such as the

>

> existence of firewalls and Network Address Translators (NATs) or the

>

> use of TLS with server-provided certificates, prevent servers from

>

> connecting to User Agents in this way.

>

> For years now the send-responses-to-via-and-requests-to-contact parts of

>

> 3261 have been ignored by SIP services serving clients connecting from

>

> the Internet. Every major SIP service out there, Twilio, OVH, ippi.com,

>

> iptel.org ..., all of them more or less ignore Contact and Via addresses

>

> and and reuse the connections they received from the client.

>

> SIP wouldn't be working over the Internet if they weren't. This is why

>

> RFC5265 was written.

>

> More inline:

>

> On 16.12.15 г. 13:32, Anatoli wrote:

>

> > Ingo,

>

> >

>

> > Thanks for your reply. There certainly may be situations where a PBX
and

>

> > an endpoint won't have a direct connection and there are (sometimes

>

> > complex) workarounds for this scenario.

>

> We are not just talking about some cases here. Except for intraLAN

>

> connections the IP address and port that come with SIP requests would

>

> never work because of the reasons pointed above. Not even for public IPs.

>

> > Nevertheless there are a lot of cases where they do have a direct

>

> > connection (LAN, VPN, etc.). And in these situations, an incorrectly

>

> > formed Contactheader impedes a correct functioning of the SIP

>

> > notification mechanism.

>

> Pooling connections and reusing sockets works just fine for these cases.

>

> > And according to the RFC 3261 (SIP: Session Initiation Protocol,

>

> > https://www.ietf.org/rfc/rfc3261.txt, 6th paragraph on page 12),

>

> > "/Contact [header] contains a SIP or SIPS URI that represents a direct

>

> > route to contact [an endpoint]/".

>

> >

>

> > A fix for this issue is simple: when preparing the Contactheader, a

>

> > client just has to specify the listening port for the connection type
in

>

> > use instead of an outgoing port.

>

> I can assure you that nothing in there is simple :).

>

> This is actually exactly what we were doing about 8 years ago and we

>

> explicitly changed it. The reason back then was that when servers needed

>

> to send requests back to Jitsi they would check the contact header and

>

> then go and look in their connection pool for a socket that already

>

> matched the address. If a connection exists they would go and reuse it.

>

> If it didn't they would create a new one. So every time we would waltz

>

> in with different addresses in Via and Contact, servers tried to connect

>

> to us on these addresses, and every time firewalls sitting in front of

>

> the clients would kill these connection attempts.

>

> So we changed it and I do believe it makes more sense that way.

>

> It is probably worth mentioning that this doesn't directly contradict

>

> RFC3261. If you are actually able to connect to our IP then we do want

>

> you to reuse the tuple from our contact header. We just don't want you

>

> to go and create a new connection. Why would you anyway?

>

> > Here Viasays "send the responses to my_ip:18372" and Contactsays

>

> > "send new requests (INVITE, NOTIFY, etc.), establishing a new TCP

>

> > session,

>

> The last part of the above sentence is where I disagree. Why would you

>

> go and insist on setting up a new TCP session? Yes, 3261 does not

>

> outright prohibit it but it pretty actively tries to encourage

>

> connection reuse. There is certainly not requirement that actually

>

> requires "establishing a new TCP session".

>

> To sum things up: things must work with the shape Jitsi's messages

>

> currently come in. Not only is this not wrong but if they didn't work

>

> that would basically mean that all Internet hosted SIP providers would

>

> break.

>

> Cheers,

>

> Emil

>

> --

>

> https://jitsi.org

>

> _______________________________________________

>

> users mailing list

>

> users@jitsi.org <javascript:_e(%7B%7D,'cvml','users@jitsi.org');> <
mailto:users@jitsi.org <javascript:_e(%7B%7D,'cvml','users@jitsi.org');>>

>

> Unsubscribe instructions and other list options:

>

> http://lists.jitsi.org/mailman/listinfo/users

>

>

>

> _______________________________________________

> users mailing list

> users@jitsi.org <javascript:_e(%7B%7D,'cvml','users@jitsi.org');>

> Unsubscribe instructions and other list options:

> http://lists.jitsi.org/mailman/listinfo/users

>

--

https://jitsi.org

_______________________________________________

users mailing list

users@jitsi.org <javascript:_e(%7B%7D,'cvml','users@jitsi.org');>

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/users

--
sent from my mobile