> But we're bellheads here and think of user-to- > user traffic as somehow different from user-to-network traffic. That, > I believe, was our first architectural mistake.
This is correct. The Internet does not have UNI and NNI but the e2e principle. Forgetting or ignoring this leads to such intractable issues. > But we're bellheads here and think of user-to- > user traffic as somehow different from user-to-network traffic. That, > I believe, was our first architectural mistake. How is one supposed to know this? Henry On 5/12/08 10:04 AM, "Dean Willis" <[EMAIL PROTECTED]> wrote: > > On May 12, 2008, at 1:59 AM, Christer Holmberg wrote: > >> >> >>>> That is not specified anywhere, and that is not general behavior. >>>> The >> registration interval offered by the UA may be something which has >> been >> provided by the operator/service >>>> provider/internet provider. And, the UA may not even know whether it >> is behind a NAT or not - at least not before it has sent some SIP >> request, after which it may check the Via etc. >>> >>> i have not followed, but isn't there a protocol called stun that an >>> ua >> should use to figure out it is behind nat or not? >> >> Sure, if the UA knows that the edge proxy supports STUN (I think we >> have >> also said that one should not send STUN requests to entities without >> knowing whether they support it or not), or the UA is aware of other >> STUN servers. > > We said one should not send STUN to the SIP port of a device without > knowing whether it supports it or not. This is to keep from either > breaking the device or having it blacklist you for sending malformed > packets. > > However, one can STUN the STUN port with less restraint. And that > would be the usage of STUN we are talking about. > > Of course, if we had sense enough to send signaling and media to/from > the same ports, then media could act as a keepalive for the signaling > while we're sending it. But we're bellheads here and think of user-to- > user traffic as somehow different from user-to-network traffic. That, > I believe, was our first architectural mistake. > > -- > Dean > _______________________________________________ > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
