[OpenSIPS-Users] Receiving requests via registration TCP connection

[Bogdan-Andrei Iancu]

Hi Iñaki,

Iñaki Baz Castillo wrote:
> 2008/10/13 Bogdan-Andrei Iancu <bogdan at voice-system.ro>:
>
>   
>>> Of course, for this to work is needed the TCP connection remains open
>>> (it could be achieved by requiring REGISTER every 32 seconds or using
>>> PING-PONG TCP keepalive if both client and server implement it).
>>>
>>>       
>> Or you can simply instruct OpenSIPS to keep open the TCP connection where
>> the REGISTER was received - see
>>   http://www.opensips.org/html/docs/modules/devel/registrar.html#id2520469
>>     
>
> Well, I tryed it for long time in OpenSer 1.2 and it never worked as
> expected. Anyway that's a different question.
>   
What did not worked? could you open a new thread on this?
>
>   
>>> But I wonder how "legal/valid" is this in RFC3261. I mean: is really
>>> valid for a proxy to send *new* requests to a registered UA via the
>>> TCP connection used for UA registration?
>>>
>>>       
>> yes, it is legal - if I'm not wrong, there is even on RFC about reusing TCP
>> connections.
>>     
>
> There is a draft about reusing TCP connections, but I just mean the
> pure RFC3261.
>   
The RFC 3261 doesn't say anything about this - nothing to confirm or to 
infirm this TCP connection reusage - there are 2 different layers - SIP 
and transport and AFAIK, there are no constrains between them.
>
>
>   
>>> Imagine UA1 sends a TCP INVITE to proxy P2 responsible for UA2 AoR. So
>>> UA1 starts a TCP connection from a random port (maybe 22222) to P2.
>>> This connection is just supposed for requests sent **by UA1** and
>>> responses sent from UA2.
>>> Now imagine that P2 sends a request to UA1 against port 22222 using
>>> the previous connection. AFAIK this is not defined in RFC3261 and UA1
>>> could just drop these requests.
>>>
>>> So I wonder which is the difference between this example and the case
>>> in with a registrar/proxy sends requests to a registered user via the
>>> TCP connection used for UA registration.
>>>
>>>
>>>       
>> A server should re-use a TCP connection only if the IP:port of the other
>> peer is the same with the IP:port of the connection.
>>     
>
> Hummm, this is just true if the server want to send a new request to a
> destinatino (got from DNS lookup) and by casuality there is also a
> open TCP connection (an existing tuple). This is:
> - The server/proxy/UA2 wants to send a request to user at domain.org.
> - By DNS it gets the IP 1.2.3.4:5060
> - It realizes that there is an existing connection to that destination
> o reuses it.
>
> But note that the Contact of a REGISTER sent from a natted client with
> pubic IP 212.10.3.25 is:
>
> TCP 192.168.1.58:11111 --> (from 212.10.3.25:12121) --> 88.99.4.100:5060
> REGISTER
> Contact: <sip:user at 192.168.1.58:5060;transport=tcp>
>
> And the registrar/proxy replies:
>
> TCP 88.99.4.100:5060 --> (to 212.10.3.25:12121) -->192.168.1.58:11111
> 200 OK
> Contact: <sip:user at 192.168.1.58:5060;transport=tcp>;received="sip:212.10.3.25:12121;transport=TCP"
>
>
> After the registration, the proxy forwards a new request to this UA
> and it sends it using the same connection (if available):
> TCP 88.99.4.100:5060 --> (to 212.10.3.25:12121) -->192.168.1.58:11111
> INVITE sip:user at 192.168.1.58:5060;transport=tcp
>
>
> So, the UA is receiving the request in the port 11111 that is a random
> port just uses to send previously the REGISTER. Why is it valid?
>
>
>   
I see what you say.
First of all, the signalling must be symmetric in order to do NAT 
traversal - the proxy is not able to send where ever the client want, 
but only to the same address where the messages came from.
So, whatever you have in Contact, the proxy will use the received 
IP:port if it wants to go through the nat. The nat will do the 
translation between the public ip:port and the private ip:port of the 
UAC. But again, being symmetric is a must for NAT traversal to work - no 
proxy can newly send or open a connection to an address behind a NAT.

>   
>> The re-usage should not
>> be done on any other criteria - only if target at IP level is the same.
>>     
>
> Is it true in the example above?
>   
when registering from behind a NAT, opensips will learn the received IP 
and used this one (and not the contact) to deliver calls. So, if the TCP 
connection of the REGISTER is still one, it will be re-used (as the 
target is the same).
>
>   
>>> Opinions? With the TCP UA's I've tryed (i-e- Twinkle) it seems to work
>>> (Twinkle accepts request from registrar/proxy coming via the TCP
>>> connection used for registration).
>>>
>>>
>>>       
>> IMO, this is bogus - a device should reject incoming calls that do not have
>> in RURI an registered contact.
>>     
>
> Bogus? well, the RURI is correct since it's exactly the Contact sent
> by the UA during registration, but the UA receives the request using
> the random port used for the REGISTER instead of receiving the request
> via the LISTENING port (5060).
> This is the main question, is it valid per RFC 3261?
>   
Not sure if the RFC3261 says something on this matter - it is more a 
logical one I would say.....Let me check, SIPit is the right place for 
this ;)

Regards,
Bogdan