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


#1

Hi Ingo,

There are a number of ways of having a host firewall and a listening port accepting connections. One is to make a rule for the incoming connections from a specific fixed IP of the PBX server on the local network. And you can even define a specific remote port range for these incoming connections, enforced on the PBX server with a firewall for a specific UID of the PBX software so no other evil app on the PBX server partially compromised will be able to talk to the client. In our case we use VoIP over VPN so we don't even have to open a port on the host's main iface.

We don't need to make dynamic outgoing ports also work as listening ports. What we need to change (either as a new option or hardcoding it into the code) is for the part responsible for the construction of the Contact field to inform (as the RFC specifies) the listening port (or omit it entirely if it’s the default port) instead of the outgoing dynamic one, so when the PBX needs to establish a connection to the client, it knows where the client listens on.

I didn't find this part of the code yet, but the change should be as simple as replacing the variable name holding the dynamic port with the name of the variable holding the listening port in the sprintf or similar function responsible for the Contact field string construction.

Something like this (a simplified pseudo-code, there option_contact_rfc would be true if we want the RFC compliant Contact field, false to maintain current behavior):

name = "JDoe";

user = "555";

ip = "10.101.100.10";

transport = "tcp";

port = (option_contact_rfc ? port_listening : port_outgoing);

strPort = (port != 5060 ? sprintf(":%s", port) : "");

strContact = sprintf("Contact: \"%s\" <sip:%s@%s%s;transport=%s>", name, user, ip, strPort, transport);

Could you please point me to the file that holds this code? And if you also tell me how Jitsi handles configuration params, I could make a complete patch for the new config option for you to consider incorporating it to the code base.

Thanks,

Anatoli

···

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

Inline

Freundliche Grüsse,

Ingo Bauersachs

-- sent from my mobile

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

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

-----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

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


#2

I pointed you to two classes/files and I can't get more specific currently as I'm travelling and only have my phone (on which Github is horrible to use).

We use the ConfigurationService to obtain options. It's used all over the place.

A pull request on Github that doesn't change the current behavior by default would be welcome. Please read our code guidelines and sign the CLA (individual https://jitsi.org/icla or corporate https://jitsi.org/ccla) before you open the PR.

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

On 17.12.2015, at 13:57, Anatoli <me@anatoli.ws> wrote:

Hi Ingo,

There are a number of ways of having a host firewall and a listening port accepting connections. One is to make a rule for the incoming connections from a specific fixed IP of the PBX server on the local network. And you can even define a specific remote port range for these incoming connections, enforced on the PBX server with a firewall for a specific UID of the PBX software so no other evil app on the PBX server partially compromised will be able to talk to the client. In our case we use VoIP over VPN so we don't even have to open a port on the host's main iface.

We don't need to make dynamic outgoing ports also work as listening ports. What we need to change (either as a new option or hardcoding it into the code) is for the part responsible for the construction of the Contact field to inform (as the RFC specifies) the listening port (or omit it entirely if it’s the default port) instead of the outgoing dynamic one, so when the PBX needs to establish a connection to the client, it knows where the client listens on.

I didn't find this part of the code yet, but the change should be as simple as replacing the variable name holding the dynamic port with the name of the variable holding the listening port in the sprintf or similar function responsible for the Contact field string construction.

Something like this (a simplified pseudo-code, there option_contact_rfc would be true if we want the RFC compliant Contact field, false to maintain current behavior):

name = "JDoe";
user = "555";
ip = "10.101.100.10";
transport = "tcp";

port = (option_contact_rfc ? port_listening : port_outgoing);
strPort = (port != 5060 ? sprintf(":%s", port) : "");

strContact = sprintf("Contact: \"%s\" <sip:%s@%s%s;transport=%s>", name, user, ip, strPort, transport);

Could you please point me to the file that holds this code? And if you also tell me how Jitsi handles configuration params, I could make a complete patch for the new config option for you to consider incorporating it to the code base.

Thanks,
Anatoli

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

Inline

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile
On 17.12.2015, at 06:45, Anatoli <me@anatoli.ws> wrote:

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

-----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
_______________________________________________
users mailing list
users@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/users