>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. Is it really register method only ? Like situation UA to B2BUA(no registrar) never can restore flow ? I thought that flow is identified by local IP:port remote:IP port and transport, like flow breaks, client opens connection with same parameters(IP:port remote:IP port and transport) and after that flow is visible to B2BUA again (like dialog also records flow). Otherwise i don't see how UA behind NAT can use TCP, because server can't open connection to client and also server cant detect restored flow.
Any comments ? Attila Sipos wrote: > 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
