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 PROTECTED] > Gesendet: Samstag, 22. M�rz 2003 05:57 > An: Christian Stredicke > Cc: [EMAIL PROTECTED]; '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 PROTECTED]: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 PROTECTED]:5060> > > ... > > > > SIP/2.0 200 Wonderful > > Record-Route: <sip:62.12.245.32:54456;nr=1> > > Contact: <sip:[EMAIL PROTECTED]: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 PROTECTED] > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
