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

[Steve Totaro]

On Sun, Jul 6, 2008 at 12:21 PM, Johansson Olle E <oej at edvina.net> wrote:
>
> 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
>

Great communication.  Way to go Digium!!!