Re: [Speermint] New Draft: SIP Interconnect Guideline

[Hadriel Kaplan <HKaplan at acmepacket.com>]

Howdy,
I read the draft and I have some comments (oh, and I support the idea of this being a WG item, BTW):

1) Section 4.1 on Extension Negotiation - the wording here is weird - a Supported header lists the extensions the specific calling UA can do for a particular request/dialog, not the whole "network".  For example one should never add a 100rel option tag (for PRACK) to a SIP request unless the UAC actually inserted it - even if both operators wish to use PRACK.  This is an important distinction because using extensions when the UAC cannot support it causes more interop problems than it solves, imo.

2) Same goes for the Allow header statement in section 4.1 - the peering partner may reduce the set allowed if the profile doesn't support it (e.g., REGISTER), but the list itself must not contain method names the UAC did not include itself.  Otherwise you'd be inserting UPDATE, for example, even if the UAC couldn't do UPDATE, and that would be bad mojo.

3) Section 4.2 - "SIP:" should be lower-case.  You should add in here that visual-separators MUST NOT be included. (they cause all sorts of issues, and were frankly a protocol layer violation to begin with, imho)

4) Section 4.2.1 - it says the receiving provider must retrieve the LNP data based on the npdi and rn parameters in the request-uri.  But as far as I know the whole point of the previous provider inserting those parameters was to indicate it had already retrieved the LNP data (which is why it inserted "npdi") and if it found the number was ported it inserted the routing number (thus the "rn").  Or maybe you mean the receiving provider must use the parameters in the request-uri as the LNP data?  I read "retrieve" and assumed it meant "go get from the LNP/NPAC database", vs. "get from request-uri".

5) Section 4.2.1 - it says if the rn param is a 10-digit national number (no "+"), then assume NANP.  That sounds sorta NANP-centric, no?  I know in practice this happens within the NANP, but if the peering is in other parts of the world or between NANP and others, it would be confusing because I think/assume that NANP numbers can actually conflict with other nations' numbers.  I think it's just better to mandate adding a leading +[country-code] if the number is not already in the E.164 format before leaving your domain.

6) Section 5.1.1 - one media line??  Why?  I mean doesn't this severely limit the providers?  How about that a provider MAY support only accepting one media line, by setting all other ones to zero port in the SDP.  We have to support offering multiple media, if for no other reason than being able to have text-based calls for audio-impaired folks (TTY).  But also it would be good to have video and BFCP and such usable, if both the other side accepts it.  I know it's caused some interop issues to have more than one, but we'll never get advanced uses if we have to fall back to broken behavior for everything. (and I distinguish between "broken" and "not what the IETF likes" - those two are not synonymous)

7) Section 5.1.2.1 - I know PRACK causes problems... LOTS of problems; but you won't be able to connect with some providers if you don't do it.  3GPP, for example, loves PRACK. (not surprising really - they love complexity ;)  And it does have tangible benefits.  Ugh.  Maybe we should just fix/change PRACK so it isn't so complicated.  Hmmm.

8) Section 5.1.2.3.1 (man that's a deep nesting of section numbers :) - I am not sure what you mean by this behavior for a Media Anchor.  (and it scares me that I don't, 'cause I build one I think)

9) Section 5.3 - hardly anyone does loop detection using History-Info, as far as I know, because it doesn't survive very far.  Have you seen that done in practice?

10) Section 5.4.1 - RFC 3603 is a PacketCable-specific header that is not used outside of PacketCable as far as I'm aware.  Also, the REFER concept is a lot trickier than that in practice, fwiw.  But you're probably getting sick of my comments by this point. :)

11) Section 5.4.2 - I believe, though I could easily be wrong, that the cited RFC 3725 and 3PCC model in general uses INVITE's with no SDP, which goes against your earlier requirement for INVITE to always have SDP.

12) Section 5.6 - RFC 4235 doesn't always work in practice across provider domains, as discussed on the SIP mailing lists recently.  And I don't know what it has to do with Callback??

-hadriel