[asterisk-dev] oej: trunk r128290 - /trunk/channels/chan_sip.c

[Johansson Olle E]

6 jul 2008 kl. 17.16 skrev Russell Bryant:

>
> On Jul 6, 2008, at 4:05 AM, Johansson Olle E wrote:
>> TCP/TLS has the same properties as UDP here. If you have a NAT,
>> neither UDP, TCP or TLS can reconnect after a long period of
>> downtime. But I fail to see a separate issue for TCP and TLS
>> without NAT.
>
>
> When using TCP or TLS without NAT, you are right, there is a good
> chance that we can reconnect.  However, just because they connected to
> us using TCP, does not mean that they are listening for incoming
> connections.
Then they break the RFC. If the register a contact with us, they need
to listen to that address.

> Also, what port would you use to reconnect?
The contact port specified in the Contact: header or, according to the  
RFC,
5060 if there's no contact but an IP address. If it's a domain,
we use the RFCs specification on how to locate the device with SRV
and DNS A records.

> Should you
> just assume 5060 and hope for the best?  You may not even connect to
> the same peer that you were connected to before.  You can't just use
> the source port from the previous connection like you can with UDP.
Which you by default can not with UDP either. But later work has added
that as an option for NAT support.

>
> But, please correct me if I'm wrong.  :)
Your comments here indicate that you need much more experience
with SIP before you make definitive statements about it and decisions
about the implementation...

I've worked hard to make chan_sip a bit more standardized and  
compliant and
that's why I do not like and react strongly when you commit stuff
that takes us back many steps... I apologize, but you have to
understand that chan_sip has been my focus for such a long time
that I want to be proud of it. I'm not proud of this version.

These issues, and a list of other things, shows that we need to work a  
lot more
on the TCP/TLS support to get things right. The commit was premature
according to your earlier mentioned rules, it should have stayed in
a branch a while more. But that's old news. Let work on fixing it
and fixing it so that it complies with both implementations and
the standards. It's important for Asterisk that we have this support,
but also that it properly interoperates with other equipment.

There are, as I mentioned in our meeting in Huntsville, some core
aspects of this that we need to consider as well before we lock
the implementation of TLS in chan_sip and move it away
from experimental status.

/O