> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Ivar > Lumi > Sent: Thursday, February 28, 2008 3:20 PM > To: Jerry Yin > Cc: [email protected] > Subject: Re: [Sip-implementors] TCP transport. > > > > >draft-ietf-sip-connect-reuse > I have readed them all. > > The problem is NAT, like UA -> NAT -> proxy. > Only UA can open connection to proxy, thats ok, UA keeps > connection open, proxy uses open connection. > Now imagine connection brakes, UA reconnects - thats ok, but now > proxy dont know connection to UA and for example proxy(b2bua) > need to send request to that UA. >
In this case, the UA would detect the connection is broken by keep-alive mechanism. Then the UA would re-register to the server (or B2BUA) and create a new AOR-Contact binding. Now when the proxy (or B2BUA) sends the request to the UA (identified by the AOR), it would find the new connection from the registration DB (IP:port). If it can't, just let the call fail. > For normal proxy thats not problem, because normally it's > registrar and forwards as normally. > But b2bua changes it all. b2bua has it's own dialogs and it must > able to send requests to UA(in this case NATted one and only UA > can open/reopen connection). And to make that more complex, > imagine that UA is not b2bua domain UA, but is foreign. > If you are talking about the outbound draft, the UA would register to the B2BUA as well. Isn't it? Even the B2BUA is not the home server (a outbound server for example), you need to create some kind of AOR-Contact bindings similar to the registration bindings so that the connection is re-used. Jerry > I must think a little, seems i really have messed my head, trying > to make all to complex. > > > > Jerry Yin wrote: > > Hi Ivar, > > > > Have a look at this draft. > (draft-ietf-sip-connect-reuse-09.txt) It may give > > you some idea about how the SIP layer creates persistent or shared > > connections. According to my understanding, the SIP call object > or related > > dialogs are independent to the under layer transport > connections. Even one > > connection is shutdown, the dialog will accept and match the > new messages > > coming from new connections. > > > > For sending requests or responses, the first step is to do DNS > query based > > on RFC3263 (for response, only need a DNS A or AAAA query). The > next step is > > to check if the connection is available or not (in the scope of > a call, or > > the whole application). If the connection is not available, the > SIP service > > layer needs to create a new connection to the destination. > > > > As to the outbound draft, it is purely used for the purpose of receiving > > incoming requests when a UA is behind a NAT/Firewall. > > > > Jerry > > > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] > >> [mailto:[EMAIL PROTECTED] > Behalf Of Ivar > >> Lumi > >> Sent: Thursday, February 28, 2008 1:42 PM > >> To: Attila Sipos > >> Cc: [email protected] > >> Subject: Re: [Sip-implementors] TCP transport. > >> > >> > >> > >> Ok, but how current solutions work ????? > >> > >> Most wont uses flow tokens, and all clients wont support them. > >> But all works, even you can plug cable out and put in (it wont break > >> dialog, some way server knows reconnected client). There should be some > >> trick. > >> > >> > >> Attila Sipos wrote: > >> > >>>>> I'm coding b2bua, and need to handle TCP,TLS UAs, so far i dont > >>>>> get 100% answer how b2bua or proxy identifies UA flow. > >>>>> > >>>>> > >>> For an incoming request, > >>> the proxy removes the Route header field value and forwards the > >>> request over the 'logical flow' identified by the flow > token, that is > >>> known to deliver data to the specific target UA instance. For > >>> connection-oriented transports, if the flow no longer exists the > >>> proxy SHOULD send a 430 (Flow Failed) response to the request. > >>> > >>> The flow is identified by the flow token which is effectively a > >>> handle into the TCP stack. > >>> > >>> When the flow is created, the server stores a handle relating > >>> to the TCP connection - it doesn't note the IP, port or anything - > >>> just a handle relating to the socket. > >>> > >>> Then when the TCP connection goes down the, TCP connection handle > >>> becomes > >>> invalid. If it tries to use that handle, it will fail and so it knows > >>> the flow doesn't exist and so can send a 430 response. > >>> > >>> > >>> > >>>>> As siad several times what i get from draft-ietf-sip-outbound, > >>>>> flow will be localIP:port + remoteIP:port + transport, is it ? > >>>>> > >>>>> > >>> no, flow will be a handle given to you by your TCP/IP stack. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> -----Original Message----- > >>> From: Ivar Lumi [mailto:[EMAIL PROTECTED] > >>> Sent: 28 February 2008 18:07 > >>> To: Attila Sipos > >>> Cc: [email protected] > >>> Subject: Re: [Sip-implementors] TCP transport. > >>> > >>> > >>> The parameters and stuff not problem. > >>> > >>> I'm coding b2bua, and need to handle TCP,TLS UAs, so far i > dont get 100% > >>> answer how b2bua or proxy identifies UA flow. > >>> And the real case, connection brakes in mid dialog, UA connects again, > >>> but how b2bua or proxy knows to use restored connection. > >>> > >>> As siad several times what i get from > draft-ietf-sip-outbound, flow will > >>> be localIP:port + remoteIP:port + transport, is it ? > >>> If so then server matches connection from active connections with that > >>> criteria. Also if client disconnects/connects server know where to try > >>> to send response back. > >>> > >>> > >>> > >>> > >>> Attila Sipos wrote: > >>> > >>> > >>>>>> But b2bua dialogs need to use UA created flows to send requests and > >>>>>> > >>>>>> > >>>>>> > >>>> responses. > >>>> > >>>> I think I understand now, maybe... > >>>> > >>>> It seems that you have a UA behind a NAT and a B2BUA in a public > >>>> address space. > >>>> > >>>> In this case, if you don't use outbound, you might still have a > >>>> problem with requests being routed to the UA behind the NAT. > >>>> > >>>> Outbound adds extra protection (with its detection of flow failure). > >>>> You could still use outbound with an INVITE as the dialog-forming > >>>> request: > >>>> > >>>> If the UA is sending a dialog-forming request, and wants all > >>>> subsequent requests in the dialog to arrive over the same > flow, the > >>>> UA adds an 'ob' parameter to its Contact header. > Typically this is > >>>> desirable, but it is not necessary for example if the Contact is a > >>>> GRUU [I-D.ietf-sip-gruu]. > >>>> > >>>> So, all requests and responses will use the flow described above. > >>>> > >>>> So, you're ok now I think. > >>>> > >>>> Regards, > >>>> Attila > >>>> > >>>> > >>>> > >>>> -----Original Message----- > >>>> From: Ivar Lumi [mailto:[EMAIL PROTECTED] > >>>> Sent: 28 February 2008 17:41 > >>>> To: Attila Sipos > >>>> Cc: [email protected] > >>>> Subject: Re: [Sip-implementors] TCP transport. > >>>> > >>>> > >>>> 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 >> >> > > _______________________________________________ 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
