RE: [Sip-implementors] A question about section 12 in RFC 3261.

[Baniel Uri-CUB001]

Proxy 2 should establish a new TCP connection from an ephemeral port (say 7129) to the listening port of P1 (5060). Section 18 of 3261 does cover that...   3261 section 18: "Note that, because the source port is often ephemeral, but it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by the transport layer will frequently not be reused.  The result is that two proxies in a "peering" relationship using a connection-oriented transport frequently will have two connections in use, one for transactions initiated in each direction." Therefore the rule above was NOT originally intent to responses in the same transactions, but was intent to subsequent requests within the same dialog. P1 should be able to correlate the incoming messages (either responses or new requests) from P2 on the same dialog based on the SIP fields that are used to identify the dialog (call ID and local/remote tags). Typically when you establish a TCP connection you are in the mercy of the Operating System wrt to the ephemeral port you would get, and the normal API would not let you re-establish the connection on your listening port. That's the background to section 18 (at least in my understanding)...   Uri ================================================================== Uri Baniel - Distinguished Member of Technical Staff - Motorola  Tel: (847) 632 4616; Fax: (847) 632 3963; "Learning that does not daily increase will daily decrease. - EWC ================================================================== -----Original Message----- From: Idnani Ajaykumar-AIDNANI1 [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 1:57 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [Sip-implementors] A question about section 12 in RFC 3261. All,   I had a question about a possible error scenario, that I feel RFC 3261 does not describe. Let me describe the scenario first, and then raise the question. Imagine a scenario where you have two UAa, that are using two different outbound Proxies, that are in a peering relationship i.e. UA1 -> Proxy1 -> Proxy2 -> UA2. Now assume a reliable transport all through. Also assume that a dialog is setup between the two UAs with the following dialog particulars   UA1 ===   local-tag = tag_ua1 remote-tag = tag_ua2 remote-target = sip:[EMAIL PROTECTED]:6123 Route-set = <sip:proxy1:5123>, <sip:proxy2:5060>   UA2 ===   local-tag = tag_ua2 remote-tag = tag_ua1 remote-target = sip:[EMAIL PROTECTED]:6234 Rooute-set = <sip:proxy2:5060>, <sip:proxy1:5123>   In this case the TCP connection between the UA1 and the Proxy1 was initiated by UA1, and has a TCP tuple of   (IP address of someotherhost.somedomain.com, 6234, IP address of Proxy 1, 5060),   where port 6234 is the ephemeral port on UA1, and port 5060 is the port that Proxy 1 is listening on.   Similarly the TCP connection between the UA2 and Proxy2 was initiated by UA2 and has a TCP tuple of   (IP address of somehost.somedomain.com, 6123, IP address of Proxy 2, 5060),   where port 6123 is the ephemeral port on UA2, and port 5060 is the port that Proxy 2 is listening on..   Now also assume that the connection between the two proxies is initiated by Proxy 1 and has the following tuple   (IP address of Proxy 1, 5123, IP address of Proxy 2, 5060),   where port 5123 is the ephemeral port on Proxy1, and port 5060 is  the port that Proxy 2 is listening on.   NOW THE QUESTION ---------------------------------   What should the Proxy 2 do, if it detects that the connection between Proxy 1, and Proxy 2 is broken? The Route set is telling Proxy 2 to send the request to port 5123 of Proxy1, but the connection to that port does not exist. I did not find any discussion of this in the SIP RFC. I did find something in Section 18 that applied to responses in the same transactions, but I am not sure if the same can be applied to subsequent requests within the same dialog.   Your help in this regard will be highly appreciated.   Sincerely - Ajay

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors