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:
>
> In cases where a network element fails, is so
> overloaded that it cannot process messages, or cannot communicate du
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 b
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
>> av
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 behin
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
inline:
Michael Thomas wrote:
> Jonathan Rosenberg wrote:
>> 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
>>> proto
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
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
CES working group scope 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 Rose
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
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 Q&A takes place. For issues related to
sip pr
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 serve
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 way
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 framewo
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
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 devic
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 .
Also
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, wrot
20 matches
Mail list logo