Richard Shockey wrote:
RS You cannot authoritatively determine a binding between a phone number
and a consumer (domain) without access to the databases.
The point of ViPR is that the authoritative mapping as you've defined it
just isn't necessary; a forward routability check is all that is
I've updated the document with your suggested wording change in REQ 15.
Thanks,
Jonathan R.
Matt Mathis wrote:
Your rewording looks good. One minor suggestion for REQ 15:
t hangText=REQ 15: In cases where a network element fails, is so
overloaded that it cannot process messages, or cannot
thanks for the comments, Matt. Responses below:
Matt Mathis wrote:
I reviewed draft-ietf-sipping-overload-reqs-02 at the request of the
transport
area directors. Note that my area of expertise is TCP, congestion control
and
bulk data transport. I am not a SIP expert, and have not been
inline:
Lars Eggert wrote:
On 2008-2-15, at 16:21, ext Bernard Aboba wrote:
However, I would suspect that clearly specifying how SCTP and DCCP
work with NAT would eventually make it possible to obtain a home NAT
supporting those protocols, particularly if implementations were made
available
inline:
Iljitsch van Beijnum wrote:
On 15 feb 2008, at 20:43, Dan Wing wrote:
Such 1-for-1 address rewriting does not provide the topology
hiding that many people seem to like of their existing NAPT
devices, nor does such 1-for-1 address rewriting obscure the
number of hosts behind the
Harald Tveit Alvestrand wrote:
While I disagree with Jonathan's assertion that we should insert an
entirely useless (for all but NAT) UDP header in front of all new
protocols we design,
Well, I'd hardly characterize, allowing it to work across the public
Internet as a property that is
Spencer Dawkins wrote:
Mind you, I'm not saying that protocols should always use a UDP
shim layer. But I think the tradeoffs in favor of doing so are a bit
stronger
than you seem to think.
This is my chance to act the naif for Valentine's Day, but ...
I agree that UDP shims improve
Iljitsch van Beijnum wrote:
On 14 feb 2008, at 21:21, Dan Wing wrote:
What seems useful is a mechanism where the UDP encapsulation can be
attempted and the native (non-UDP encapsulted) protocol can be
attempted.
I was thinking along similar lines. Notwithstanding what I said
earlier,
I wrote this because of a discussion that happened during behave at the
last IETF meeting in Vancouver. There was a presentation in the behave
working group on NAT ALG for SCTP - when run natively over IP - and I
found the entire conversation surreal. The entire problem would have
been moot if
is limited (by chart) to the case where the
control element is near the forwarding element. I am not worried about
there being a NAT between those. So SCTP or DCCP over IP is very relevant.
Yours,
Joel M. Halpern
Jonathan Rosenberg wrote:
I wrote this because of a discussion
Following Patrik's lead, I wanted to let the IETF community know that I
am not planning to re-up for IAB either. I've enjoyed my 2 years on the
IAB, but my day job is making it increasingly difficult for me to
dedicate the time IAB deserves.
Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.
Questions on IMS should probably be directed towards 3gpp mailers, since
that it is where it is being standardized. For SIP questions, you should
direct your queries to sip-implementors@cs.columbia.edu, which is where
general implementation help and QA takes place. For issues related to
sip
These topics are being discussed in the simple working group. I'd
suggest you direct future queries there as they are likely to result in
a faster response.
To briefly answer your question, a SUBSCRIBE is also used to query. The
Expires header field is set to zero. This tells the presence
inline.
Tony Hain wrote:
Joel M. Halpern wrote:
This discussion seems to take as a premise the view that if we define
applications only on IPv6, even though they could be defined on IPv4, that
this will give people a reason to use IPv6.
It also seems to take as a premise that if we don't define
Let me try to clarify here.
The IETF has two standards-track techniques for DTMF carriage. These are:
1. RFC 2833
2. KPML and the app interaction framework (draft-ietf-sipping-kpml,
draft-ietf-sipping-app-interaction-framework). This uses a
subscribe/notify model to carry user input.
The
inline.
Michael Richardson wrote:
Harald And - here I am making a real leap of faith - if the IETF
Harald recommendations for NAT devices make manufacturers who
Harald listen to them create NAT devices that make their customers
Harald more happy, then many of these new NAT devices
inline.
Michael Richardson wrote:
I agree with Melinda.
I would very much like to be able to let the desk clerk at the hotel
know that I won't be paying for their Internet service, because it
wasn't RFC compliant. (I now wish that someone did get the trademark
on that word, and would deny it
These questions are specific to the iptel group. Please direct your
questions there ([EMAIL PROTECTED]), and I'm sure folks will be happy to
answer them.
-Jonathan R.
iptel co-chair
jyoti wrote:
Hello ,
Please can you tell if there has been any commercial use of TRIP
anywhere in the world .
One of the challenges in producing an Internet Draft is the creation of
ASCII art call flow diagrams (aka sequence diagrams), such as those in
http://www.ietf.org/rfc/rfc3665.txt. I tend to do a lot of these in the
drafts I write.
To make the process easier, a colleague of mine, Dave Ladd,
19 matches
Mail list logo
