Don't need outbound, but for example UA is not b2bua domain one(foreign one), does SRV/A lookup, connects to b2bua UA(user). But b2bua dialogs need to use UA created flows to send requests and responses.
I don't see that such case is not allowed . Attila Sipos wrote: >>> UA connects to b2bua server, so UA does not need to register anywhere. >>> > > > If you are only routing calls from UA to b2bua server, why do you > need to use outbound at all? > > > > > > > > > -----Original Message----- > From: Ivar Lumi [mailto:[EMAIL PROTECTED] > Sent: 28 February 2008 16:52 > To: Attila Sipos > Cc: [email protected] > Subject: Re: [Sip-implementors] TCP transport. > > > >> However, if you don't use registration of some kind, how is the B2BUA >> going to know where the UA is? >> > UA connects to b2bua server, so UA does not need to register anywhere. > > > yep 4.3 > > If the UA cannot use one of the existing flows, then it SHOULD form a > new flow by sending a datagram or opening a new connection to the next > hop, as appropriate for the transport protocol. > --------------------------- > But doesn't that mean no register needed and flow is identified by > endpoints and transport only. > > Over all instance-ID and register .... i get from there if proxy is > registrar too, it can use other any connection, otherwise it can use > only flow that did request(it has no knowledge of other connections from > UA). > > > > > > > Attila Sipos wrote: > >>>> 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
