At 08:53 PM 7/5/2007, Henning Schulzrinne wrote:
Let me try to explain:
Let's say proxy P1 inserts location information L1, and user agent U1
inserts L2. I want to identity L1 and L2, not necessarily the IP
addresses or host names for proxy P1 or user agent U1 (which may or
may not be unique, if NATs are involved).
<light goes on>
this is important... many of us had realized this was a problem, I
just didn't realize this new header solved it (yet). It will now!
The reason is simple - some element may insert location information,
and the poor sender will try to figure out an error for location
information it has never inserted.
I think this should be in all responses,
all? even 5XXs and 6XXs? I'm have a pragmatic attack thinking how
in the world a UAS can process enough of a request to figure out
location is bad, but still error the message because of something it
can't do more fundamentally with the request outside of
location. There aren't that many 5XX and 6XX responses, so I'm not
fighting it - just trying to understand what you want.
I'm open to all 4XX (cuz I can see this working in most 4XX responses
(like a double error of "this *and* that" were wrong with this
request), which is why I offered it (instead of limiting this to just the 424).
as calls may succeed even if
the location information, or one piece of it, happens to be bad. I
still want to know that the call may have been routed without taking
the location information into consideration, say, and why.
The 3261 generic-param is fine with me.
good!
Thanks!
Henning
On Jul 5, 2007, at 9:45 PM, James M. Polk wrote:
Question - what's the difference between "...he location element
that suffers from the problem identified..." mentioned above and
how you "... don't feel strongly about identifying the originator
of the error". Aren't they the same node?
If not, I need to understand, as I define what ID goes into this
header.
Another point - should this error header only be in the 424 (Bad
Location Information) response, or all 4XX responses, allowing a
transaction to be successful - but without the location piece of
the information exchange being good?
This was discussed, but I don't think the discussion ever concluded.
_______________________________________________
Sip mailing list https://www1.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
