Subject: [Sip] Comments on sip-outbound-13

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 7 Apr 2008 16:15:42 -0400

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.

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.

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.

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."

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)

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.

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.

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...".

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"?

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/

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.

-hadriel
_______________________________________________
Sip mailing list  https://www.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: "Rohan Mahy" <[email-masked]>
Date: Mon, 7 Apr 2008 14:49:50 -0700

>  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…

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 loa…

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.?

>  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 concurren…

good

>  Insert "limited" before "Session". (ie, it is not a full STUN server)

good

>  Add "and port" at the end.

good

>  "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…

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.

>  The logic flow is awkward there.  Change second sentence to start with "Alternatively, the UAC could...".

better

>  I think what you mean at the end is instead "without using the outbound mechanism"?

yes

>  s/production in/resolved for/

I don't think your proposed rewording is correct.  Perhaps s/next
hop/next hop URI/ ?

>  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 stre…

How about:
s/stream-based/connection-oriented/  ?

thanks,
-rohan

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 8 Apr 2008 22:48:05 -0400

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
>

It does? Geesh. What a tangled web of dependencies we weave. ;)

> >  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.
>

I ask because one could get a 3xx for Register at any time, for example while there is an established dialog over that flow.  (but it would be weird, and we can't account for all bizarre corner cases)
At the end of section 4.2.1, add:
"If the registering UA receives a 3xx response to the REGISTER request, such that it moves its registration "flow", it SHOULD reuse the same reg-id value for the moved REGISTER."

> >  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.
>

Ahh, then maybe it's a missing comma that screwed me up.  Should be:
"It also provides an easy way to guarantee uniqueness, within the AoR, when multiple UA's are registered for the same AOR."
Otherwise to me it looked like it was claiming the instance guaranteed uniqueness [to] the AoR.

> I don't think your proposed rewording is correct.  Perhaps s/next

OK.  Is "production" a common use for it?  Maybe s/production in/portion of/ as well as your URI addition?

> >  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:

Cool with me.

-hadriel

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 10 Apr 2008 08:14:49 -0700

Hi,

>  "If the registering UA receives a 3xx response to the REGISTER request, such that it moves its registration "flow", it SHOULD reuse the same reg-id value for the moved REGISTER."

I think it may already say to do something like that overall in
another place.  I'll take a closer look and see if it adds or detracts
from the overall clarity of the document.

>  Otherwise to me it looked like it was claiming the instance guaranteed uniqueness [to] the AoR.

I think this is more confusing with the extra commas, and the RFC
editor is likely to just remove them anyway.  (I remember paragraph
upon paragraph in the Replaces or MWI spec where the only change
between the RFC and the approved ID where a bunch of commas removed.)

>  > I don't think your proposed rewording is correct.  Perhaps s/next

Actually when I looked at the text again, it is completely wrong.  If
the certificate has a domain name in subjectName, but no
subjectAltName, the UA should compare against that too.

>  OK.  Is "production" a common use for it?  Maybe s/production in/portion of/ as well as your URI addition?

Yes. FYI: "production" has a very specific meaning.  It refers to a
name used inside the BNF.  The host production in the RFC 3261 is
shown here:

SIP-URI = "sip:" [ userinfo ] hostport uri-parameters [ headers ]
...
hostport = host [ ":" port ]
host = hostname / IPv4address / IPv6reference

thanks,
-rohan