Subject: [Sip] Comments on draft-ietf-sip-hop-limit-diagnostics-00

From: "Samir Srivastava" <[email-masked]>
Date: Thu, 2 Mar 2006 03:40:08 -0600

Hi,

1.   Draft proposes 
      "Any 483 response SHOULD be constructed with a message body of
type
      message/sipfrag containing as much as possible of the SIP header
      from the rejected request."

  A Proxy receives the request on UDP, and forwards on the TCP , when it
receives the response, message becomes more than 1300 bytes (If complete
req needs to be copied). Proxy doesn't have TCP transport to send 483
with complete Message. It need to chop down some of the headers. It will
be good to provide some guidance on what headers to chop down.
Especially via chopping should be
done at the last. It is obvious, better it is stated.

2. What B2BUA / SBC will do, there purpose is topology hiding. They will
not provide the meaningful
   guidance as MAX HOP COUNT is reached in the hidden network. It needs
to be mentioned somewhere 
   too. 

Thx
Samir

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Scott Lawrence <[email-masked]>
Date: Thu, 02 Mar 2006 09:54:57 -0500

> to be mentioned somewhere 

The latter is addressed in the Security Considerations section:

   4.  Security Considerations

   The proposed mechanism provides a means by which topology and some
   routing information about a set of SIP systems can be discovered.
   The mechanism is very similar to that provided for IP routing by the
   traceroute tool.

   Some systems may not want to expose as much information as is
   available in the full set of SIP request headers by returning them in
   the error response body.  It is suggested in this case that at least
   all of the Route and Via headers from the request be returned in the
   message/sipfrag body.  In the example (Section 2.3), this would at
   least enable the end user to determine which proxies were in the
   routing loop and how the request arrived there, but not the specific
   address transformations that caused the loop.

I suppose that if a system wanted prune the response to fit into 1300
bytes, the recommendation about what to trim would be the same.  If the
consensus is it wouldb be better to move that to a section of its own
and then reference it for both purposes, that would be an easy change.

<rhetorical_question>
When are we going to all just agree that reassembling UDP is essential
and get it done? 
</rhetorical_question>

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  Consulting Engineer - Pingtel Corp.  http://www.pingtel.com/
  sipXpbx project coordinator - SIPfoundry  http://www.sipfoundry.org/sipX