rfc 3261 18.1
For reliable transports, the response is normally sent on the
connection on which the request was received. Therefore, the client
transport MUST be prepared to receive the response on the same
connection used to send the request. Under error conditions, the
server may attempt to open a new connection to send the response. To
handle this case, *the transport layer MUST also be prepared to
receive an incoming connection on the source IP address from which
the request was sent and port number in the "sent-by" field.
----------------------------------------------------------------------------------
*From there i see 2 possibilities to cover that:
1) forge sent-by to some listening address:port and open connection from
random port. (so far don't see what refuses it)
2) stack also listens on same local ip:port what sent request.
But now that means if stack has 1 listening point, 1 physical
connection can be made between 2 hosts only.
(TCP won't allow more than 1 connection on: localIP:port -
remoteIP:port, it has now means to distinguish connection otherwise)
*
*Anyway flow when client restores flow, how server knows the flow.
For example server is B2BUA, in mid dialog flow breaks, client opens it,
how server know the new client flow ?
(Only point what i get is flow token is like (localIP:pot -
remoteIP:port - transport),client must restone same parameters
connection and server searches it from existing connections)
It's messy part, rfc not 100%, many drafts updating, .. - hard to get it
done right
Attila Sipos wrote:
> Hi Ivar,
>
> can you give me the text in 18.1 that you are referring to?
>
> Regards,
>
> Attila
>
>
>
> -----Original Message-----
> From: Ivar Lumi [mailto:[EMAIL PROTECTED]
> Sent: 28 February 2008 11:34
> To: Attila Sipos
> Cc: [email protected]
> Subject: Re: [Sip-implementors] TCP transport.
>
>
> But doesn't connection must liten also on same local IP end point, as
> rfc 3261 18.1 says ... .
>
> Like SIP client - 192.168.1.10:5060 wants to connect to
> 192.168.1.11:5060, then:
> SIP client startrs listen on 192.168.1.10:5060, sends request from
> 192.168.1.10:5060 to 192.168.1.11:5060.
> (Normally there is 1 IP address and 1 listening port, so at this case 1
> physical connection can be done between 2 hosts) But at this case on new
> connections can't be opened, or port or IP must be different !!!!
> Correct me if i miss somethings.
>
>
>> Then for calls arriving at the SIP proxy, the call can be routed to the
>>
>
>
>> UA using the "flow".
>>
> But now what defines flow (lcoalIP:port,remoteIP:port,transport ????) Or
> if not, for example TCP flow fails, client restores flow , but how SIP
> proxy knows new flow then ?
>
> >However this requirement does not stop you from making other >SIP TCP
> connections.
> From my understanding, you may do as long as IP or port differs and
> also you need to listen incoming connection on each new port you send
> out. But in real life such case hard to maintain, because fiewalls, ...
> you you need to open range of ports for SIP.
>
> Probably i really miss the point ...
>
> Attila Sipos wrote:
>
>> I think the most important thing with outbound is that the UA must
>> always maintain the TCP connection for the "flow".
>>
>> Then for calls arriving at the SIP proxy, the call can be routed to
>> the UA using the "flow". You have to keep the flow alive to receive
>> calls.
>>
>>
>> However this requirement does not stop you from making other SIP TCP
>> connections. You are allowed to make as many as you want as long as
>> you maintain the "flow" connection.
>>
>> Regards,
>> Attila
>>
>>
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> Ivar Lumi
>> Sent: 28 February 2008 09:29
>> To: [email protected]
>> Subject: [Sip-implementors] TCP transport.
>>
>> Hi,
>>
>> According rfc 3261 18.1
>>
>> For reliable transports, the response is normally sent on the
>> connection on which the request was received. Therefore, the client
>> transport MUST be prepared to receive the response on the same
>> connection used to send the request. Under error conditions, the
>> server may attempt to open a new connection to send the response. To
>> handle this case, the transport layer MUST also be prepared to receive
>>
>
>
>> an incoming connection on the source IP address from which the request
>>
>
>
>> was sent and port number in the "sent-by" field. It also
>>
>> //-------------------------------------
>> Request sending connection must also listen incoming connection on
>> same local end point.
>> From there comes that there can be only 1 connection between 2 SIP
>> devices if both have only 1 IP address and they are listening in 1
>>
> port.
>
>> device 1(192.168.1.10:5060) ------- device 2(192.168.1.10.5060)
>>
>> Or only possibility is to forge sent-by value to listening port and
>> open each connection on it's own port.
>> But this again brakes draft-ietf-sip-outbound-12.txt, if new ports
>> every time, SIP proxy can't detect flow reconnect if connection
>>
> braked.
>
>> (If i get right flow is defined by local enpoint,remote endpoint and
>> transport)
>>
>> Do i miss something or there is always 1 connection ?
>>
>> Any comments would be very welcome.
>>
>> Thanks,
>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>>
>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
