Ok, I see where you are now. 5060 is the TCP listening port but when you make a new SIP call, the TCP connection's local port is not 5060, it will be something else. Normally, if there are no error conditions, the response will come back using the same TCP connection. If there is an error condition, it gets sent the place defined by sent-by.
So, to make it work, you have to put 5060 into the sent-by even if that isn't the local port created by the new TCP connection. This is to make sure the error condition is covered. now outbound... For outbound, since we are considering NAT traversal for SIP signalling, the information in the sent-by won't be correct with respect to the edge proxy. So the error condition can't be handled in the same way. For outbound, the "flow" is set up using a REGISTER. The SIP proxy using outbound will record the source IP and port of TCP connection. As long as the flow is maintained, all requests for that UA will get sent to the recorded IP and port. Requests from the UA should also use the flow. And so all responses will get sent back using the same flow. Anyway to answer questions... >>1) forge sent-by to some listening address:port and open connection from >> random port. (so far don't see what refuses it) yes >>2) stack also listens on same local ip:port what sent request. no. not needed. option 1) is good. >>*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 ? it is up to the UA to detect a flow failure - when it does detect flow failure, the UA needs to do a new REGISTER to set up the flow again. The proxy doesn't know about new flows, it only knows if a flow exists or not. Normally a request to a non-existent flow will get a "430 Flow Failed" response. So I guess the UA would have to decide what to do in this case. Regards, Attila -----Original Message----- From: Ivar Lumi [mailto:[EMAIL PROTECTED] Sent: 28 February 2008 12:24 To: Attila Sipos Cc: [email protected] Subject: Re: [Sip-implementors] TCP transport. 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
