>>Is it really register method only ? Looking at the introduction...
The key idea of this specification is that when a UA sends a REGISTER or a dialog-forming request, the proxy can later use this same network "flow"--whether this is a bidirectional stream of UDP datagrams, a TCP connection, or an analogous concept of another transport protocol--to forward any incoming requests that need to go to this UA in the context of the registration or dialog. Then later section "3.1. Summary of Mechanism"... The overall approach is fairly simple. Each UA has a unique instance-id that stays the same for this UA even if the UA reboots or is power cycled. Each UA can register multiple times over different connections for the same SIP Address of Record (AOR) to achieve high reliability. Each registration includes the instance-id for the UA and a reg-id label that is different for each flow. The registrar can use the instance-id to recognize that two different registrations both reach the same UA. The registrar can use the reg-id label to recognize whether a UA is creating a new flow or refreshing or replacing an old one, possibly after a reboot or a network failure. When a proxy goes to route a message to a UA for which it has a binding, it can use any one of the flows on which a successful registration has been completed. A failure to deliver a request on a particular flow can be tried again on an alternate flow. Proxies can determine which flows go to the same UA by comparing the instance-id. Proxies can tell that a flow replaces a previously abandoned flow by looking at the reg-id. And section "3.2. Single Registrar and UA" For clarity, here is an example. Bob's UA creates a new TCP flow to the registrar and sends the following REGISTER request. >>Like situation UA to B2BUA(no registrar) never can restore flow ? section "4.3. Sending Non-REGISTER Requests" talks about establishing a flow if not using REGISTER. But I don't think this establishes a flow in the normal sense - it will only. However, if you don't use registration of some kind, how is the B2BUA going to know where the UA is? >>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). The proxy/registrar knows about the remote port:ip etc but not directly. The REGISTER uses a TCP connection and the registrar stores a TCP connection handle of some kind. When a SIP request is for the registered outbound UA, it uses the TCP connection handle to route the message. >>Otherwise i don't see how UA behind NAT can use TCP, because server can't >>open connection to client and also server can't detect restored flow. I don't see how it can work without using REGISTER. Like I said before, if you don't use REGISTER, how is the B2BUA going to know where the UA is? Regards, Attila -----Original Message----- From: Ivar Lumi [mailto:[EMAIL PROTECTED] Sent: 28 February 2008 14:40 To: Attila Sipos Cc: [email protected] Subject: Re: [Sip-implementors] TCP transport. >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
