Subject: [Sipping] Re: AW: "Strict Routing", "Loose Routing", "No Routing"!

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 23 Mar 2003 22:54:59 -0500

Christian,

I cannot really follow your email, and do not understand the problem 
here. Perhaps you are referring to the case where A calls B, both behind 
the same NAT, with a proxy on the public Internet. If the proxy doesnt 
record route, a contact in the INVITE from A that contains an address 
allocated via upnp will not be useful to B. There is an equivalent case 
for RTP.

There are only two solutions for this, I believe:

1. the proxy always record routes. But, how does it know that it needs 
to do so?

2. apply the ICE principles to SIP signaling. This would involve 
inclusion of *both* the public and private addresses in the Contact 
header of the INVITE, and so the recipient uses the one that works. 
Contact in INVITE only allows one URI (pity), so we would need to hack 
around to get that to work. There are ways.

I think most folk do approach 1. Its problem is that the proxy has to 
know to record route.

Approach 2 is in line with the ICE philosophy in that it would always 
work, without requiring apriori topology knowledge as case 1 assumes.

Anyway, moving to sipping since this is an important issue.

-Jonathan R.

Christian Stredicke wrote:
> Rohan,
> 
> that is surely going into the right direction!
> 
> I think it clearly points out the need to transport more than one
> address in the SDP.
> 
> However, it does not seem to solve the problem for requests that don’t
> have SDP attachments (like MESSAGE). There is a difference in SIP
> routing and RTP routing. I think the draft addresses the RTP routing
> problem. For SIP routing, I think we still need a way for formulating
> that non SIP-aware equipment is involved in the routing process.
> 
> Again, in my perception, SIP deals with *routes* (user agent client,
> number of routers with loose/strict/no routing and the user agent
> server). Every router has a defined behaviour (SIP aware called
> "proxies" and non SIP-aware called "NAT"). We know that the different
> types of proxies need different treatment and I begin to realize that
> NAT routers need a different treatment as well.
> 
> The good news is that "no-routers" can be treated backward compatible.
> If the routing element behind the no-router fixes the SIP routing
> information everything should run fine. It is also the element behind
> the no-router that inserts this information. 
> 
> Anyway, having a STUN server on board of every SIP network element
> (UA/proxy) is probably a good idea for whatever comes. As you know, we
> did this already half a year on our proxy!
> 
> Best,
> 
> 
> Christian
> 
> 
>>-----Ursprüngliche Nachricht-----
>>Von: Rohan Mahy [mailto:[email-masked]]
>>Gesendet: Samstag, 22. März 2003 05:57
>>An: Christian Stredicke
>>Cc: [email-masked]; 'Jörgen Björkner'; 'Robert
> 
> Sparks'
> 
>>Betreff: Re: "Strict Routing", "Loose Routing", "No Routing"!
>>
>>Hi Christian,
>>
>>Have you seen Jonathan Rosenberg's "ICE" proposal which we discussed
> 
> in
> 
>>SIPPING?  How do you think these would relate.
>>
>>thanks,
>>-rohan
>>
>>
>>On Monday, March 17, 2003, at 09:17 PM, Christian Stredicke wrote:
>>
>>
>>>Hello again,
>>>
>>>while we have now loose routers and strict routers it seems that a
>>
> new
> 
>>>type occurs on the horizon: The "no router"!
>>>
>>>This is for example the case when using NAT forwarding (e.g. with
>>
> STUN
> 
>>>or UPnP). The router is not at all aware of SIP and does not
>>
> manipulate
> 
>>>the packet at all. However, the router is too dumb to forward a
>>
> packet
> 
>>>if it is coming from the wrong direction. This is the case with most
>>
> of
> 
>>>the DSL routers today.
>>>
>>>May I propose to use a ";nr" flag in a URI to indicate that the
>>
> router
> 
>>>does not do any SIP changing at all?
>>>
>>>User Agents that are able to deal with "no routers" would then
>>
> register
> 
>>>with the following packet:
>>>
>>>REGISTER sip:bla.com SIP/2.0
>>>Path: <sip:62.12.245.32:54456;nr=1>
>>>Contact: <sip:[email-masked]:5060>
>>>...
>>>
>>>When it receives a message this could look like this:
>>>
>>>INVITE sip:62.12.245.32:54456;nr=1 SIP/2.0
>>>Route: <sip:[email-masked]:5060>
>>>...
>>>
>>>SIP/2.0 200 Wonderful
>>>Record-Route: <sip:62.12.245.32:54456;nr=1>
>>>Contact: <sip:[email-masked]:5060>
>>>...
>>>
>>>The nr parameter could easily indicate that the previous router did
>>
> not
> 
>>>change the packet at all and that the next entity has to fix this
>>>before
>>>processing the message. Alternatively, the router sending the packet
>>>could fix the route before sending it.
>>>
>>>What do you think? Is this really necessary? Just omit the nr
>>
> parameter
> 
>>>and conclude implicitly? How else should we deal with routers that
>>
> are
> 
>>>not SIP-aware? I don’t like the route encoding in the header
>>>(sip:abc?route=def) as it raises many questions about how to merge
>>
> this
> 
>>>with other existing routes.
>>>
>>>Unfortunately, omitting the private address is no solution, as
>>
> devices
> 
>>>in the same subnet have to bypass the "no router". Many DSL routers
>>
> are
> 
>>>not able to send packets from private address via the public address
>>
> to
> 
>>>the other private address.
>>>
>>>Cheers,
>>>
>>>
>>>Christian
>>>--
>>>Dr. Christian Stredicke
>>>sip:[email-masked]
>>>
>>
> 
> 

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 24 Mar 2003 23:43:41 -0500

Christian,

Your note below jumps right to solutions and I am still trying to 
understand your problem. Notes inline.

Christian Stredicke wrote:
> Jonathan,
> 
> ok I elaborate a little bit as the history might not be known to
> everybody.
> 
> (1) I am talking about the SIP messages here only; RTP is a separate
> issue.
> 
> Again, I would like to stress I am not trying to reinvent routing (I
> think that would be too late and inappropriate anyway). I would just
> like to propose a backward-compatible way of expressing that non-SIP
> aware equipment is involved in the message forwarding process that needs
> to be taken care of. There is a need for this as we are moving on making
> the addresses found by STUN usable between the different vendors.
> 
> (2) The problem is that depending on the context a request must be send
> to one of several possible addresses. In the case of NAT you are right,
> this is typically a problem when the two user agents are in the same NAT
> and the NAT gateway does not properly forward the messages coming from
> the private side sent to the public address of the other phone. This is
> my private concern as this is the most critical case we are facing in
> day-to-day life now. 

Well, lets get specific.

I think we are principally dealing with Contacts placed in INVITE/200 
OK, and Contact in REGISTER, to make sure they are reachable by whomever 
is sending the request. THe main case I know of is when a proxy doesnt 
record route and two clients not behind the same nat call each other.

> 
> (3) I proposed using alternative addresses in the contact like 
> 
> "sip:62.12.34.56:6546;srcadr=192.168.0.123:5060"
> 
> but that did not find too much acceptance with the persons that I talked
> to. The alternative proposal is including the route in the contact like

Hang on a sec.

You are jumping right to the assumption that the fix is to include 
additional addressing information in the URI. There are other solutions. 
My observation is that this is all a non-problem when dealing with 
proxies which have record-routed. IN such a case, I see no problems. So 
the trick is how does a proxy know it NEEDS to record route (or insert 
itself in a Path). There are ways to perhaps determine that as well.

> 
> "sip:192.168.0.123:5060?Route=sip:62.12.34.56:6546" or so,
> 
> but this has the disadvantage that equipment which does not support the
> route header will not be able to send the packet properly (and apart
> from that I have some problems understanding how the route header should
> be merged with a maybe existing route).
> 
> (4) What I propose now is using the routing mechanism we all know from
> SIP with a modification (backward compatible). For registrations, the
> path header has already been proposed and the record-route is part of
> the RFC. 
> 
> Lets make an example: The UA is in a private network and has the above
> private address and public address association. So it will send the
> following REGISTER message:
> 
> Path: <sip:62.12.34.56:6546;nr=1;lr>
> Contact: <sip:192.168.0.123:5060>
> ...
> 
> The registrar will save both the path and the contact. So a INVITE that
> is forwarded to the user agent then will go along the path:
> 
> INVITE sip:192.168.0.123:5060 SIP/2.0
> Route: <sip:62.12.34.56:6546;nr=1;lr>
> 
> Because the user agent can deal with the "no routing", it will remove
> the top route entry (it contains the nr) and then process the packet.
> Here, it will probably start ringing.
> 
> If the user agents sends a message and the topmost route entry contains
> the nr flag, it skips that route if the IP address is the same as the IP
> address that is has stored as its public IP address. 

Stored? How does one UA store the IP address from some other one?

This is surely a
> pragmatic first step to solving the problem of finding the right
> destination in a NAT. However, it can be extended to using STUN probes
> first and so on (for example in multi-tier NAT). 
> 
> (5) The nice thing about the nr idea is that existing equipment does not
> have to be changed. That means especially the existing proxies in the
> public internet can deal perfectly with "no routers". If equipment
> supports the nr flag, it will also see the packets with the nr flag and
> process them accordingly. Meaning that nr is fully backward compatible.

I still do not know what you mean by a "no router".

-Jonathan R.

---

From: "Christian Stredicke" <[email-masked]>
Date: Mon, 24 Mar 2003 16:48:46 +0800

Jonathan,

address that is has stored as its public IP address. This is surely a

I hope this clarifies the idea a little bit more.

Christian
--
Dr.-Ing. Christian Stredicke
sip:[email-masked]

> Von: Jonathan Rosenberg [mailto:[email-masked]]
> Gesendet: Montag, 24. März 2003 11:55
> An: Christian Stredicke
> Cc: 'Rohan Mahy'; [email-masked]; 'Jörgen Björkner'; 'Robert Sparks'
> Betreff: Re: AW: "Strict Routing", "Loose Routing", "No Routing"!
> 
> Christian,
>

---

From: "Cullen Jennings" <[email-masked]>
Date: Mon, 31 Mar 2003 08:23:06 -0800

Consider the case where there are three NATs calls A B and C. Both A and B
are behind C. This is typical where C is a ISP and A and B are home nats.
Two phones behind A and B both think their pubic address is the address on
the outside of C.

I'm not sure I understand what you are proposing but I suspect it might not
work in this case.

Cullen

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Christian Stredicke
> Sent: Monday, March 24, 2003 12:49 AM
> To: 'Jonathan Rosenberg'
> Subject: [Sipping] AW: AW: "Strict Routing", "Loose Routing", "No
> Routing"!
>
>
> Jonathan,
>