[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Comments on sip-outbound-13
On Mon, Apr 7, 2008 at 1:15 PM, Hadriel Kaplan <HKaplan at acmepacket.com> wrote:
> Howdy,
> I have the following comments, mostly editorial nits, on the latest draft. I think these do not overlap with John Elwell's.
>
> General comment: I think it's in great shape, and very thorough.
Thanks!
> 1) I do not see any discussion of RFC 3680 SIP Registration Event Package. I assume that each registered flow's contact is treated as a unique contact in all regards to RFC 3680, right? And the reg-id and instance would be saved in the "unknown-param" XML element of the contact element, making those unique (vs. being unique contact URI's). I think maybe that should be clarified somewhere, as rfc3680 is not uncommon.
Paul K had an extension to reg-event for GRUU. I think his document
would be a logical place to clarify since GRUU depends on outbound.
> 2) If a Register is 3xx redirected, does the new retargeted Register use the same reg-id, even though it's a different "flow"? (I assume so) I ask because some people use 3xx for Registers to load-balance or perform anycasting. It may be good to add this to end of section 4.2.1.
Yes, the UA uses the same reg-id. It uses the the reg-id to indicate
that this is (for example) my "2nd logical flow" to my registrar or
the logical flow over my "cellular interface". Can you suggest
something here or point out the specific part that is confusing.?
> 3) Page 5:
> Reg-id: "When a UA registers multiple times, each concurrent registration gets a unique reg-id value." Replace with: "When a UA registers multiple times, each for a different flow, each concurrent registration gets a unique reg-id value."
good
> 4) Page 12, Section 3.5.2:
> The proxy or registrar acts as a Session
> Traversal Utilities for NAT (STUN) [I-D.ietf-behave-rfc3489bis]
> server on the SIP signaling port.
> Insert "limited" before "Session". (ie, it is not a full STUN server)
good
> 5) Page 12, Section 3.5.2:
> Note: The STUN mechanism is very robust and allows the detection
> of a changed IP address.
> Add "and port" at the end.
good
> 6) Page 12, Section 4.1:
> "It also provides an easy way to guarantee uniqueness within the AOR." I'm a bit confused by that, because I don't believe we're saying one UA instance only ever represents one AoR. (ie, multiple AoR's registered on the same UA will have the same registered contact instance) Recommend removing or rewording.
I don't see the confusion. _Within_ the AOR, the instance-id provides
further disambiguation. I can absolutely use the instance with more
than one AOR.
> 7) Page 14, Section 4.2.1:
> For each outbound proxy URI in the set, the UAC SHOULD send a
> REGISTER request using this URI as the default outbound proxy. (The
> UA could limit the number of flows formed to conserve battery power,
> for example).
> The logic flow is awkward there. Change second sentence to start with "Alternatively, the UAC could...".
better
> 8) Page 15, Section 4.2.1:
> If the registering UA receives a 439 (First Hop Lacks Outbound
> Support) response to a REGISTER request, it MAY re-attempt
> registration without an outbound proxy (subject to local policy at
> the client).
> I think what you mean at the end is instead "without using the outbound mechanism"?
yes
> 9) Page 16, Section 4.3:
> ... For TLS protocols, there MUST also
> be a match between the host production in the next hop and one of the
> URIs contained in the subjectAltName in the peer certificate.
> s/production in/resolved for/
I don't think your proposed rewording is correct. Perhaps s/next
hop/next hop URI/ ?
> 10) Page 18, Section 4.4.1:
> A User Agent that forms flows, checks if the configured URI to which
> the UA is connecting resolves to a stream-based transport (ex: TCP
> and TLS over TCP).
> That's confusing, because double-CRLF is used for connection-oriented transports period, not only stream-based ones (ie, also used for SCTP). And no statement is made about why it checks for stream-based, so I recommend removing it or clarifying.
How about:
s/stream-based/connection-oriented/ ?
thanks,
-rohan
> -hadriel
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip