Subject: [Sipping] I-D Action:draft-ietf-sipping-sbc-funcs-05.txt

From: [email-masked]
Date: Tue, 25 Mar 2008 03:30:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Proposal Investigation Working Group of the IETF.

	Title           : Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments
	Author(s)       : J. Hautakorpi, et al.
	Filename        : draft-ietf-sipping-sbc-funcs-05.txt
	Pages           : 25
	Date            : 2008-03-25

This document describes functions implemented in Session Initiation
Protocol (SIP) intermediaries known as Session Border Controllers
(SBCs).  The goal of this document is to describe the commonly
provided functions of SBCs.  A special focus is given to those
practices that are viewed to be in conflict with SIP architectural
principles.  This document also explores the underlying requirements
of network operators that have led to the use of these functions and
practices in order to identify protocol requirements and determine
whether those requirements are satisfied by existing specifications
or additional standards work is required.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-sbc-funcs-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Hendrik Scholz <[email-masked]>
Date: Mon, 31 Mar 2008 10:34:05 +0200

Hi!

Section 3.2. Media Traffic Management only describes one to one
media streams.
One UAC sends/receives one stream which is relayed through an SBC.

What happens if the call forks and the UAC could receive multiple
early media streams?
From my point of view the SBC should never expose more than one
media stream towards the UAC and terminate/supress additional
streams where needed.

Shouldn't this be documented as a requirement?

Best Regards,
 Hendrik

-- 
Hendrik Scholz <[email-masked]>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 31 Mar 2008 09:52:28 -0400

That is an interesting area since we attempted to use forking in the case of
an originating SBC (connected to the PSTN eventually). There seem to be
multiple cases:

1) Forking happens in the call path beyond the SBC (case above): In this
case, the SBC will end up terminating the forking since it is a B2BUA.

2) Forking happens before the (forked) calls hits the SBC. In this case, the
SBC may not know the difference since they all appear as different calls.
There may be multiple SBCs as well terminating different branches of the
fork.

So I am not sure we need to document anything extra here. (I did notice that
the SBC we were exposed to in our scenario (1) couldn't handle forking at
all. It would not send an ACK to all but one 200 OKs - that's is a separate
issue though).

Medhavi.

-- 
Medhavi Bhatia

CTO, 3CLogic
www.3clogic.com

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 31 Mar 2008 12:41:17 -0400

*Why* should the SBC prevent more than one media stream from being seen 
by the client?

Depending on why you are deploying the SBC in the first place, you might 
want this I suppose. But that doesn't mean everybody wants it.

	Thanks,
	Paul

---

From: [email-masked]
Date: Mon, 31 Mar 2008 18:02:21 -0500

From: Hendrik Scholz <[email-masked]>

Why should this be a requirement?  SIP UAs are already prepared to
handle it.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 31 Mar 2008 20:50:44 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Hendrik Scholz
>

A requirement for whom?  The only real requirements I am aware of in the sbc-funcs draft are the ones derived from some SBC functions, for the purpose of documenting a few functions that there should/could be a SIP-UA way to provide/do.  A SIP-UA can already ignore or not ignore multiple media streams as it sees fit.

For an SBC, that "requirement" is specific to the application, provider, or vendor.  Just like blocking early media or blocking specific media codecs, for example.  Some providers want/need that, others don't.

-hadriel