Subject: [Sip] Determining if a call _can_ function

From: David Benoit <[email-masked]>
Date: Mon, 6 Mar 2006 16:50:07 -0400

Hi,

When placing a SIP call from certain network locations, your ability to
receive incoming messages may be limited.  One major problem is
determining if a call can actually function from one endpoint to another.
Consider the following scenario:

- Alice is a subscriber to a reasonable ISP that doesn't allow inbound TCP
  connections to "random things"
- Alice wishes to call Bob.

Pretty simple.

So, obviously Alice's UAC should choose UDP to initiate the call and
everything will work.  However, there is a gotcha.  If Alice has a UAC
that supports a LOT of codecs, or requires a large nonce in the
authentication header, etc., Section 18.1.1 or RFC 3261 comes into play.
So, if Alice's UAC _has_ to use TCP or TLS (if Bob was at "sips: ...")
then there is a problem.

This is what will happen.  The INVITE will be sent to Bob's UAS, the
response messages will be, properly, sent back to Alice's UAC on the TCP
connection on which the INVITE was received, and Alice's UAC will send the
ACK (as a new transaction) directly to Bob's UAC (possibly skipping any
proxies involved with the initial INVITE).

Now, if Bob's UAS/UAC implements RFC 4028 timers, then when Bob's UAS/UAC
negotiates itself as the refresher it can't send a new transaction to
Alice's UAC because a TCP connection can't be made to Alice's machine.
The refresh will fail and the call will be killed at Bob's end.

Even if neither implements timers, or Alice's UAC is the refresher, then
when Bob wishes to hangup, the BYE message can't be sent to Alice's UAC
for the same reasons.

This situation can be detected by Bob's UAS/UAC while processing the
INVITE.  It can attempt to send a transaction to Alice's UAC and if any
response to that transaction is received, the call should be able to
continue without issue.

 Alice's UAC        Bob's UAS/UAC
     |                  |
     |----- INVITE ---->|
     |<------ 100 ------|
     |   X<--- PING ----|
     |   ECONNREFUSED ->|
     |<------ 6XX ------|
     |------- ACK ----->|

And here's one if Alice's ISP removed that restriction:

 Alice's UAC        Bob's UAS/UAC
     |                  |
     |----- INVITE ---->|
     |<------ 100 ------|
     |<----- PING ------|
     |---- [2456]xx --->|
     |<------ 200 ------|
     |------- ACK ----->|

In this case, Bob's UAS/UAC knows that it will be able (unless the rules
are changed mid-session) that proper message flow can occur.

The introduction of a new 6xx code to indicate that the Contact
information presented in the INVITE is unusable would allow Bob's UAS to
tell Alice's UAC about this condition.

This would fit with the intended use of the PING method in determining the
validity of the signaling path.  This does impose extra cost on all TCP
calls.

Is there an alternative way to detect this scenario?

David
-- 
[email-masked] | phone: 902-832-2649  fax: 902-832-1015
 "Complex problems have simple, neat and wrong solutions" - H. L. Menken

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 06 Mar 2006 17:46:36 -0500

This problem is solved with draft-ietf-sip-outbound, which ensures that 
the outbound connect initiated by a client towards its proxy is used for 
all incoming messages, both new calls and mid-dialog requests in the 
reverse direction.

-Jonathan R>

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Dale R. Worley" <[email-masked]>
Date: Mon, 13 Mar 2006 17:33:22 -0500

>  Alice's UAC        Bob's UAS/UAC

I don't think this solves the problem in many cases like the one you are
outlining.  Because once Alice has a TCP connection set up, going out
through whatever NAT-like arrangement is involved, Bob's attempt to send
to Alice's TCP contact address works -- The PING is likely to take the
reverse path of the INVITE, and thus get routed to the SIP agent which
is the other end of the TCP connection that Alice has made.  Pretty much
line the response to the INVITE will be routed.  So Bob's PING will be
successful, but only because the TCP tunnel is open at that time.  But
neither Bob nor Alice has any good way of knowing that.

I think the best available solution is for Alice's UAC to use a contact
that it positively knows is globally routable, not only in regard to
addressing, but also in regard to TCP vs. UDP issues.

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 13 Mar 2006 18:06:44 -0600

> addressing, but also in regard to TCP vs. UDP issues.

Of course, the only way to be absolutely assured that a contact is  
globally routable is to exercise it from every node on the globe,  
using both TCP and UDP as you describe.

That being rather unsassertable, we find ourselves in one of three  
real use cases:

1) A UA that knows its contact is NOT globally routable by inspection  
(aka, RFC 1918 or autoconfig ranges).

2) A UA that  knows its contact is NOT globally routable by exercise  
-- it has STUNned a node, somewhere, that returns a different address  
from the one the UA believes itself to be using.

3) A UA that isn't sure. It knows that its contact MIGHT not be  
globally routable, but can't really prove it.

So some point, we have to think about not global routability, but  
relative routability. Can this UA see that UA directly? If so, they  
can talk. if not, they need a helper node or nodes (STUN, TURN, or  
both) that can see both UAs, or a chain of helper nodes such that the  
each end of the chain is visible to one UA, and the intermediate  
nodes in the chain form a continuity path.

This distinction doesn't mean a lot in our more conventional SIP  
deployments, but becomes quite significant in P2P-SIP work, where we  
might have two overlay networks, each running in autoconfig address  
space, but connected by a pair of relay agents.

Something to think about.

--
Dean