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

From: "Christian Stredicke" <[email-masked]>
Date: Mon, 31 Mar 2003 20:11:10 +0200

Yes that's the problem we are facing every day: Calling your "neighbour"
in the same NAT. 

Maybe I should write a draft about this which explains the why, how, and
so on. Maybe this should be renamed to "NAT routing" -- sounds less
revolutionary:-)

BTW I think that it is not a replacement of lr - its just another
routing information. I now think a Route could look like this:

Route: <[email-masked]:60765;nr=nat;lr>
Route: <[email-masked];5060;lr>

The nr=nat indicates that this part of the route has to be handled
according to the "nat" scheme. Other schemes might follow.

Christian

> -----Ursprüngliche Nachricht-----
> Von: Cullen Jennings [mailto:[email-masked]]
> Gesendet: Montag, 31. März 2003 18:23
> An: Christian Stredicke
> Cc: [email-masked]
> Betreff: RE: [Sipping] AW: AW: "Strict Routing", "Loose Routing", "No
> Routing"!
> 
> 
> 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'
> > Cc: 'Rohan Mahy'; [email-masked]; 'Jörgen Björkner'; 'Robert
Sparks'
> > Subject: [Sipping] AW: AW: "Strict Routing", "Loose Routing", "No
> > Routing"!
> >
> >
> > 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.
> >
> > (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
> >
> > "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:
> >
> > REGISTER sip:bla.com SIP/2.0
> > 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. 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 hope this clarifies the idea a little bit more.
> >
> >
> > Christian
> > --
> > Dr.-Ing. Christian Stredicke
> > sip:[email-masked]
> >
> >
> > > -----Ursprüngliche Nachricht-----
> > > 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,
> > >
> > > 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
> >

_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Tue, 8 Apr 2003 15:44:08 -0700

Hi,

Sorry for the delay.  This mail got lost for in my Drafts folder

inline...

On Monday, March 24, 2003, at 12:48 AM, Christian Stredicke wrote:

> (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,
> 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.
>
> to. The alternative proposal is including the route in the contact like
>
> but this has the disadvantage that equipment which does not support the

there are really two cases here. for no modifications to the client, 
there are no proposed solutions. if we are making modifications to the 
client, this seems like the smallest change to me.  The existing 
language in 3261 describes how to do the merging in an implicit way.  
If you want to make it more explicit that is fine.  (The pre-loaded 
Route is appended to the default route-set is on the other side.

> (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
> The registrar will save both the path and the contact. So a INVITE that
> 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.
> 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. This is surely a
> destination in a NAT. However, it can be extended to using STUN probes

you don't need to do this, because you can use STUN to figure out if 
your address is valid in the public context.

> have to be changed. That means especially the existing proxies in the
> 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.

well, you are requiring new functionality on proxies instead of making 
the end-systems deal with basic health and hygiene. somebody has to do 
the work, but i prefer if it is the user agents.

thanks,
-rohan

>> Cc: 'Rohan Mahy'; [email-masked]; 'Jörgen Björkner'; 'Robert Sparks'
>> I cannot really follow your email, and do not understand the problem
>> 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
>> 1. the proxy always record routes. But, how does it know that it needs
>> to do so?
>>
>> 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
>> 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.
>>
>>> I think it clearly points out the need to transport more than one
>>> address in the SDP.
>>>
>>> have SDP attachments (like MESSAGE). There is a difference in SIP
>>> routing and RTP routing. I think the draft addresses the RTP routing
>>> Again, in my perception, SIP deals with *routes* (user agent client,
>>> number of routers with loose/strict/no routing and the user agent
>>> If the routing element behind the no-router fixes the SIP routing
>>> 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
>>>> Have you seen Jonathan Rosenberg's "ICE" proposal which we discussed
>>>
>>> in
>>>
>>>> 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
>>>
>>>>> This is for example the case when using NAT forwarding (e.g. with
>>>>
>>> STUN
>>>
>>>>> 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
>>>>> and conclude implicitly? How else should we deal with routers that
>>>>
>>> are
>>>
>>>>> (sip:abc?route=def) as it raises many questions about how to merge
>>>>
>>> this
>>>
>>>>> in the same subnet have to bypass the "no router". Many DSL routers
>>>>
>>> are
>>>
>> Chief Scientist                             Parsippany, NJ 07054-2711
>> dynamicsoft