Subject: [Speermint] New Draft: SIP Interconnect Guideline

From: Daryl Malas <[email-masked]>
Date: Wed, 04 Mar 2009 16:37:52 -0700

All,

We have submitted a new draft beginning a process for defining a SIP
interconnect guideline for peering.   Of the operators I have spoken with
regarding their experiences with peering, SIP interworking is the most
challenging process to work through.  Establishing a guideline will be a
fundamental step in enabling SSPs to peer quickly, efficiently, and
dynamically.

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

    Title           : draft-hancock-sip-interconnect-guidelines-00
    Author(s)       : D. Hancock, D. Malas
    Filename        : draft-hancock-sip-interconnect-guidelines-00.txt
    Pages           : 25
    Date            : 2009-03-04

As Session Initiation Protocol (SIP) peering becomes more widely
accepted by service providers the need to define an interconnect
guideline becomes of greater value.  This document takes into
consideration the SIP and commonly used SIP extensions, and it
defines a fundamental set of requirements for SIP Service Providers
(SSPs) to implement within their signaling functions (SFs) or
Signaling Path Border Elements (SBEs) for peering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-hancock-sip-interconnect-guideline
s-00.txt

Regards,

Daryl

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199
mailto:[email-masked]

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 Mar 2009 14:36:30 +0000

Daryl, David,
 
I like the initiative, and I was wondering whether it could apply
between two enterprise networks as well as between two service provider
networks. However, I think it might be too restrictive (e.g., limiting
just to a single audio medium).
 
One particular concern is that it is specified in terms of "networks",
whatever that might mean, whereas endpoints (SIP UAs) will be
responsible for many aspects, e.g., anything to do with SDP, provision
of local ringback tone, etc..
 
One item of interest is section 5.1.2.3 "Early media with multiple
terminating endpoints". The correct way of achieving this in SIP is the
third method (5.1.2.3.3), i.e., using multiple early dialogs. Another
way, not mentioned here, is to use redirection as a means of creating a
new dialog. I am concerned about the media anchor method (5.1.2.3.1),
because that would constrain the call to using whatever attributes
(e.g., codec) are negotiated between the calling UA and the anchor, and
would deny the possibility of using a superior codec end-to-end if
supported by both UAs. Also it would prevent end-to-end security using
security descriptions (say), since the security context negotiated with
the anchor would be used throughout the call. The early answer method
(5.1.2.3.2) is likely to mislead the calling side as to what is actually
happening.
 
There seems to be a whole lot missing in the area of transport,
authentication, etc..
 
John

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of Daryl Malas
	Sent: 04 March 2009 23:38
	To: [email-masked]
	Cc: David Hancock
	Subject: [Speermint] New Draft: SIP Interconnect Guideline

	All,
	
	We have submitted a new draft beginning a process for defining a
SIP interconnect guideline for peering.   Of the operators I have spoken
with regarding their experiences with peering, SIP interworking is the
most challenging process to work through.  Establishing a guideline will
be a fundamental step in enabling SSPs to peer quickly, efficiently, and
dynamically.
	
	A New Internet-Draft is available from the on-line
Internet-Drafts directories.
	
	    Title           :
draft-hancock-sip-interconnect-guidelines-00
	    Author(s)       : D. Hancock, D. Malas
	    Filename        :
draft-hancock-sip-interconnect-guidelines-00.txt
	    Pages           : 25
	    Date            : 2009-03-04
	
	defines a fundamental set of requirements for SIP Service
Providers

http://www.ietf.org/internet-drafts/draft-hancock-sip-interconnect-guide
lines-00.txt
	
	Regards,
	
	Daryl
	
	-----------------
	Daryl Malas
	CableLabs
	(o) +1 303 661 3302
	(f) +1 303 661 9199

---

From: "PFAUTZ, PENN L, ATTCORP" <[email-masked]>
Date: Thu, 5 Mar 2009 11:49:47 -0500

Daryl:
David:
 
I took a quick look at the I-D and want to be sure I understand what's
being said about  called user identification. In Section 4.2.1 is the
identification of the rn in  the case of a ported number just for sub
subsequent interworking back to SS7/circuit switched networks or
something else? I tend to think of ENUM-based routing mechanisms as
being portability corrected to begin with so number portability info
should only be required where subsequent interworking has to take place.

 thanks,
 
Penn Pfautz
AT&T Access Management
+1-732-420-4962

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Daryl Malas
Sent: Wednesday, March 04, 2009 6:38 PM
To: [email-masked]
Cc: David Hancock
Subject: [Speermint] New Draft: SIP Interconnect Guideline

All,

interconnect guideline for peering.   Of the operators I have spoken

Regards,

Daryl

-----------------
Daryl Malas
CableLabs
(o) +1 303 661 3302
(f) +1 303 661 9199

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 05 Mar 2009 12:53:22 -0500

We¹re planning to set aside time on our agenda to have the authors present
this draft.  We will also be gauging WG interest in making this an official
WG item.

Thanks
Jason

On 3/4/09 6:37 PM, "Daryl Malas" <[email-masked]> wrote:

> http://www.ietf.org/internet-drafts/draft-hancock-sip-interconnect-guidelines-
> 00.txt
> 
> Regards,
> 
> Daryl
> 
> -----------------
> Daryl Malas
> CableLabs
> (o) +1 303 661 3302
> (f) +1 303 661 9199
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 06 Mar 2009 17:07:07 +0000

> -----Original Message-----
> From: David Hancock [mailto:[email-masked]] 
> Sent: 05 March 2009 21:29
> To: Elwell, John; Daryl Malas; [email-masked]
> Subject: RE: [Speermint] New Draft: SIP Interconnect Guideline
> 
> Thanks for the comments, John.
> 
> Additional comments inline below.
> 
> David
> 
> > -----Original Message-----
> > From: Elwell, John [mailto:[email-masked]]
> > Sent: Thursday, March 05, 2009 7:37 AM
> > To: Daryl Malas; [email-masked]
> > Cc: David Hancock
> > Subject: RE: [Speermint] New Draft: SIP Interconnect Guideline
> > 
> > Daryl, David,
> > 
> [dch] I think the scope of this work is open to discussion. 
> The idea was
> to start smaller rather than larger in terms of scope; provide
> guidelines for basic voice services as a doable first step, and then
> layer on more advanced capabilities as a future activity.
> 
> > 
> [dch] Our intention was to use the terminology and 
> architecture already
> defined for speermint. Although I notice that
> draft-ietf-speermint-terminology doesn't define the term "networks" so
> we may need to tighten up the terms in our draft to ensure there's no
> ambiguity in what we're talking about. As far as what entities must
> comply with these guidelines, I've been thinking of it like 
> this - these
> guidelines define the SIP signaling procedures as they appear on the
> interface between two peering networks. In other words, this draft
> places requirements on a peer network (using speermint terminology).
> Whether this requirements are met by a SIP endpoint served by that
> network, or an SBE (speermint term) at the peer interface point, is
> out-of-scope. 
> 
> > 
> > way, not mentioned here, is to use redirection as a means 
> of creating
> a
> [dch] I agree that the forking option in 5.1.2.3.3 is the preferred
> option. We added the other media-anchor and early-answer options to
> reflect what's happening in the field today. Should these 
> other options
> be ruled out as not supported, or allowed as long as operators are
> willing to live with their inherent limitations? 
> 
> I hadn't thought of the using redirect in this context, but I agree it
> would work for some use cases (like call-forwarding 
> no-answer, where the
> called user identity changes). But I think there are some use cases
> where it wouldn't work (where the called user identity 
> doesn't change);
> e.g., user-A in peer network-1 calls user-b in peer network-2, and
> user-B has solicitor call blocking with pin override. The 
> call is first
> routed to a media server in network-2 to prompt for and 
> collect the PIN
> from user A (via a 2-way early-media session), and then delivered to
> user B which sends a 180 response with no SDP (on a new dialog) to
> instruct user-A's endpoint to provide local ringback tone. Does this
> line up with your understanding?
[JRE] I think it could be made to cover that situation too, by including
some sort of cookie in the 3xx contact URI or an embedded Route header
field, so that the new INVITE request can be linked to state in the
downstream SP.

John

> [dch] Agreed, am open to expanding the scope of this initial draft to
> cover other common interworking issues, as long we're pragmatic about
> what can be accomplished in a reasonable timeframe.
> 
> > 
> > John
> > 
> > 
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 9 Mar 2009 02:31:34 -0400

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