Might I ask how this work overlaps or aligns with the efforts of the = recently created INSIPID and STRAW WGs?

Mike

From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of = Cristina Badulescu
Sent: Monday, July 16, 2012 2:15 = PM
To: adam@nostrum.com; rai@ietf.org
Cc: = Jerry.Shih@att.com
Subject: [RAI] FW: Expert Review of 6 new = SIP header fields defined by OMA CPM = 1.0

De= ar Adam,

I'= m acting as OMA CPM Convenor, picking up this = thread from my predecesor. Pls find my answers inline below. =

Re= gards,
Cr= istina

From: Rohnert, Hans (NSN - DE/Munich)
Sent: Tuesday, March = 20, 2012 1:22 PM
To: 'ext Adam Roach'
Subject: RE: = [RAI] Expert Review of 6 new SIP header fields defined by = OMA

Dear Adam,

Thank you for reviewing the OMA CPM headers.

I act as Convenor for OMA CPM and will reply to this. It will just = take a few more days.

Thanks,

Hans

From: rai-bounces@ietf.org = [mailto:rai-bounces@ietf.org] = On Behalf Of ext Adam Roach
Sent: Monday, March 19, = 2012 10:27 PM
To: RAI Area
Cc: RAI Area = Directors
Subject: [RAI] Expert Review of 6 new SIP header = fields defined by OMA

I have been asked by the RAI area = directors to review of the SIP header fields proposed by the following = OMA document:

http://www.= openmobilealliance.org/Technical/release_program/docs/CPM/V1_0-20101012-C= /OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C.pdf

I have been = designated the formal expert reviewer for this request from OMA. = Although this is not the formal review (which will be sent in response = to a request from IANA), the contents of my review will be identical to = or substantially similar to the following if the current proposal is = sent to IANA. OMA is encouraged to make adjustments as suggested below = before = proceeding.

------------------------------------------------------= ----------------

The OMA proposal "CPM Conversation = Functions" describes six new SIP header fields. These header fields = are intended to facilitate their SIP- and MSRP-based instant messaging = architecture. I will address each proposed header field individually, = using the criteria described in section 4 RFC 5727.

In = particular, I am analyzing for a lack of overlap with existing (either = complete or in-progress) work in RAI; the absence of significant changes = in SIP client behavior; and proper treatment of security-related = issues.

My first comment, which is global, is that this document = nearly universally uses the term "header" where "header = field" is intended. While this is largely editorial, RFC3261 does = have a clear definition for the term "header," and its use in = this fashion is nonsensical. This does not preclude registration of the = header fields.
&n= bsp;

[C= ristina] CPM 1.0 is now in it's final approval process in OMA, so = we will incorporate the IETF terminology correction in CPM = 2.0.

----------------------------------------
Conversati= on-ID

Conclusion: Apparently unsuitable for registration = (significant client behavior change), can be fixed with clearer = semantics describing client behavior when header field is absent.&n= bsp;

[C= ristina] Conversation-ID is mandatory in CPM, so if the header field is = not present then it's a typical protocol error = case.

This proposed header field does not appear to = directly conflict with existing or ongoing work in the RAI area. = However, its presence is likely superfluous, as the SIP Call-ID of the = initial message in the conversation could trivially be used for this = purpose: it has the same information properties as the proposed = Conversation-ID.
&n= bsp;

[C= ristina] OMA CPM has the concept of "Conversation" which = groups together for example chat sessions, file transfers, standalone = messages, subsequent disposition notifications e.g. 'delivered' = /'display' for missed messages that are delivered/read later. The = Conversation content (messages, file tranfers, notifications, etc) is = identified and stored all together, by the Conversation-ID which ties = them all together. Call-ID was not used since these IDs are = expected to simply be copied over at B2BUA's so they will remain the = same on an end to end basis (passing through = SBCs).

After carefully reviewing both = OMA-TS-CPM_Conv_Fnct-V1_0-20101012-C and = OMA-TS-CPM_System_Description-V1_0-20101012-C, I have serious concerns = about whether this header field qualifies as "purely = informational" and as "NOT significantly chang[ing] the = behavior of SIP entites that support it." In particular, both = documents contain normative language indicating behavior such as the = following:

"[T]he CPM = Participating Function... SHALL extract and locally store the following = headers of the request: From header; To header; Date header, if it = exists; Conversation Identity and Contribution Identity and if there is, = Contribution Identity being replied to."

This text, for = example, leaves the behavior undefined when a Conversation Identity = header field is not present in the SIP message. Many implementations = will consequently fail to process the request when no Conversation-ID = header field is sent, which is the most radical behavior change = possible.

[C= ristina] Co= nversation-ID is mandatory in CPM 2.0. So if the header field is = not present in the SIP message received by the CPM participating = function, then it'll be a failure at protocol level and the CPM = session will not be initiated. Hence CPM Participating Function = will not get to record a closed CPM session, which is the = execution point quoted above (i.e. to extract the headers for = storing/recording purposes).

Ca= ll-Id was not used since the values of these headers should be created = and used in a way unrelated to Call-Id. These ID's are expected to = simply be copied over at B2BUA's so they will remain the same on an end = to end basis (passing through SBCs). We wanted to avoid any cases where = SBCs could alter the new headers in any way (e.g. even a blind = replacement of the ['@' word]" part).

Al= so, the same Conversation-ID of the previous chat INVITE would have to = be used in CPM scenarios where a closed chat session is revived later on = by any one of the original participating UAs (i.e. re-initiating = it). As this later UA could be in a different domain, carrying the = original ['@' word]" part does not serve any purpose (but can be = confusing).

To be acceptable for registration under RFC = 5727 guidelines, the behavior described in this document (and related = documents that discuss conversation behavior) need to be revised to = clarify that the absence of this header field cannot result in = substantial changes in client behavior, such as failure to process the = message.

I will observe that the use of the initial Call-ID of = the conversation to identify the entire conversation (as suggested = above) completely eliminates these concerns, as RFC3261 mandates the = presence of Call-ID in every SIP message.

Since the header field = is not presently suitable for registration, I will not perform a = security analysis for = Conversation-ID.

----------------------------------------
Contr= ibution-ID

Conclusion: Apparently unsuitable for registration = (significant client behavior change), can be fixed with clearer = semantics describing client behavior when header field is = absent.

This proposed header field does not appear to directly = conflict with existing or ongoing work in the RAI area. However, its = presence is likely superfluous, as the SIP Call-ID of the message could = trivially be used for this purpose: it has the same information = properties as the proposed Contribution-ID.

I have concerns = congruent with those for Conversation-ID, in that behavior in the = absence of the Contribution-ID is not well defined, and therefore will = likely lead to interoperability failures (which constitute significant = changes in client behavior). For example:

"[T]he CPM Participating Function... SHALL, in = case of a Pager Mode CPM Standalone Message, store the following = information: ... Contribution-ID; InReplyTo-Contribution-ID (if = present)."

This comment may be = addressed in the same way as for Conversation-ID.

[C= ristina] Similar answer as for Conversation-ID answer applies = to the Contribution-ID for Call-ID reuse and mandatory nature for all = CPM SIP methods. =

I will again observe that the use of Call-ID for this = function eliminates all interoperability concerns.

Since the = header field is not presently suitable for registration, I will not = perform a security analysis for = Conversation-ID.

----------------------------------------
InRep= lyTo-Contribution-ID

Conclusion: Suitable for registration, once = security is addressed

This proposed header field does not appear = to directly conflict with existing or ongoing work in the RAI area, and = client behavior in its absence appears to be well defined = (communications proceed as expected).

Note that the use of = Call-ID for identification of contributions would allow the use of the = already-defined SIP "In-Reply-To." Doing so eliminates the = need for the definition and registration of a new header = field.

[C= ristina] This header field has an eq= uivalent syntax to the Contribution-ID, used to correlate messages & = disposition notifications within one specific = Conversation.

This = header field needs to include a discussion of security: if new users are = included into an ongoing conversation, the presence of this header field = can be used to deduce that they did not receive previously sent messages = on the topic. The very existence of these messages may constitute = sensitive information that the sender did not intend to reveal. In = particular, senders should have the ability to suppress this header = field to avoid leaking such = information.

----------------------------------------
Session-R= eplaces

Conclusion: Unsuitable for registration (overlap with RAI = work)

This proposed header field directly conflicts with the = "Replaces" header field defined by RFC 3891, which constitutes = existing work within the IETF RAI area. It is not suitable for = registration.

I do not believe that the described mechanism can = be altered to overcome this conflict. OMA should instead employ the = mechanism defined by RFC 3891.

[C= ristina] The main problem encountered with "Replaces" was that = SBGs along the way (or B2BUA) alter the Call-ID value contained in this = header field. This beats the purpose in the service logic in CPM, as we = absolutely needed to identify the Contribution-ID of the original = session being replaced. So the Session-Replaces contains the original = Contribution-ID value (not Call-ID).

----------------------------------------
Message= -Expires

Conclusion: Suitable for registration, once security is = addressed

This header field avoids overlap with existing RAI work = by careful scoping its use to the INVITE method. Client behavior in its = absence appears to be well defined, and does not constitute a = significant change in SIP client behavior.

This header field = needs better discussion of its security properties. In particular, = implementors need to ensure user expectations around what happens when a = message expires are properly dealt with. For example: if a user sends a = message which he expects to expire in one hour, there is no guarantee = that the recipient will be unable to retrieve the message after that = time. Further, the recipient device may not preclude the storage of = received messages well past their expiration.

[C= ristina] it was left as an implementor's choice how to deal with this = case, hence not intended for the standard = specification. =

----------------------------------------
Message-UID

Co= nclusion: Suitable for registration

This header field does not = appear to overlap with any existing RAI work. Client behavior in its = absence appears to be well defined, and does not constitute a = significant change in SIP client behavior.

The presence and use = of this header field does not appear to introduce any security = issues.

/a

Thank you for the comprehensive analysis and feedback= , I=20 understand the RFC5727 (esp. sect. 4) better at this point.

I will take the IETF RAI conclusion back in= to=20 OMA for consideration and assessment of the next steps.=20

Best regards,
/Cristina

From: Adam Roach [mailto:adam@nostrum.c= om]=20
Sent: July-16-12 5:53 PM
To: Cristina=20 Badulescu
Cc: rai@ietf.org; Jerry.Shih@att.com
Subject:= Re:=20 FW: [RAI] Expert Review of 6 new SIP header fields defined by OMA CPM=20 1.0

Cristina:

Thank you for your clarifying= =20 comments. It is now clear that RFC 5727 expert review processes are unlikel= y to=20 apply to the CPM header fields at all. If your replies are accurate, then a= ll of=20 the CPM 1.0 header fields (with the possible exception of Message-UID) must= be=20 processed through the normal IETF Standards Track process, which requires t= he=20 mechanism to be developed in an IETF working group. If OMA's official posit= ion=20 is that communication fails in the absence of these header fields, then I=20 suggest that you quickly bring a proposed set of requirements to the SIMPLE= =20 working group so that the IETF work can begin in earnest.

On the oth= er=20 hand, if you would prefer to register header fields under RFC 5727 section = 4=20 procedures -- without the need to publish them via the IETF Standards Track= =20 process -- then you must make them conform to the criteria in RFC 5727 sect= ion=20 4. In my original message, I indicated how to do this for every proposed he= ader=20 field (save Session-Replaces, which I discuss below). Re-asserting as immut= able=20 facts the very properties that violate RFC 5727 section 4 criteria is not=20 sufficient to bring them out of violation; actual changes are required.
=
I=20 have specific responses inline, below.

On 7/16/12 1:15 PM, Crist= ina=20 Badulescu wrote:

----------------------------------------<= BR>

Conversation-ID

Conclusion: Apparently unsuitabl= e for=20 registration (significant client behavior change), can be fixed with clea= rer=20 semantics describing client behavior when header field is absent.

[C= ristina]=20 Conversation-ID is man= datory in=20 CPM, so if the header field is not present then it's a typical= =20 protocol error case.

[Cristina]=20 Conversation-ID is mandatory in CPM 2.0. So if the header field is not=20 present in the SIP message received= by the=20 CPM participating function, then it'll be a failure at protocol level and the CPM = session=20 will not be initiated.
If=20 the presence, absence, or value of the header field can cause the communica= tions=20 to fail, then it is not subject to registration under RFC 5727 section 4=20 procedures (numbered criteria 1, in particular). You must instead bring the= =20 mechanism to the IETF for refinement and eventual publication as a=20 standards-track RFC.

To be clear: you claim that absence of the head= er=20 field causes the communication to fail. I can imagine no more radical behav= ioral=20 change than the conversion of success into failure.

Based on your an= swer=20 above, Conversation-ID must not be registered under RFC 5727 section 4=20 procedures.

[Cristina] Sim= ilar=20 answer as for Conversation-ID answer applies to the Contribution-ID = for=20 Call-ID reuse and mandatory nature for all CPM SIP=20 methods.

Bas= ed on=20 this answer, Contribution-ID also must not be registered under RFC 5727 sec= tion=20 4 procedures. See my response above.

----------------------------------------
Session-Rep= laces

Conclusion:=20 Unsuitable for registration (overlap with RAI work)

This proposed= =20 header field directly conflicts with the "Replaces" header field defined = by=20 RFC 3891, which constitutes existing work within the IETF RAI area. It is= not=20 suitable for registration.

I do not believe that the described=20 mechanism can be altered to overcome this conflict. OMA should instead em= ploy=20 the mechanism defined by RFC 3891.

[Cristina] The main problem encountered with=20 "Replaces" was that SBGs along the way (or B2BUA) alter the Call-ID value= =20 contained in this header field. This beats the purpose in the service log= ic in=20 CPM, as we absolutely needed to identify the Contribution-ID of the origi= nal=20 session being replaced. So the Session-Replaces contains the original=20 Contribution-ID value (not=20 Call-ID).

If the SBCs= are=20 altering the Call-IDs, then it is incumbent on those SBCs to make correspon= ding=20 adjustments to the "Replaces" header field. Re-inventing the SIP protocol i= n a=20 parallel set of header fields as a vain attempt to stay ahead of SBCs' abil= ity=20 to disrupt services through data alteration engages in a cat-and-mouse game= that=20 cannot be won. Any rationale that can be applied to claim that such SBCs wi= ll=20 leave Contribution-IDs unmolested can be applied equally to Call-IDs.
The=20 proposed header field remains in competition with an existing standards-tra= ck=20 mechanisms, in violation of the RFC 5727 admonishment that experts are to=20 "review documents for overlap with existing chartered work in the RAI Area.= " It=20 cannot be registered as long as it remains in competition with RFC=20 3891.

To suggest a concrete path forward: I will first re-iterate th= at=20 this kind of operation must be performed using the mechanism defined in RFC= =20 3891. If SBC survivability remains an issue, I would suggest that you bring= work=20 to the IETF that extends RFC 3891 to optionally use the end-to-end identifi= ers=20 presently undergoing specification in the INSIPID working group. I would be= gin=20 by discussing such a need on the DISPATCH working group mailing list: https://www.ietf.or= g/mailman/listinfo/dispatch

In=20 my opinion, it would be easier for OMA operators to clarify to the vendors= =20 selling them SBCs that a criteria for selection of such SBCs includes Repla= ces=20 header field Call-ID fix-up for Call-ID changes perpetrated by the=20 SBCs.

----------------------------------------
Message-Exp= ires

Conclusion:=20 Suitable for registration, once security is addressed

This header = field=20 avoids overlap with existing RAI work by careful scoping its use to the I= NVITE=20 method. Client behavior in its absence appears to be well defined, and do= es=20 not constitute a significant change in SIP client behavior.

This h= eader=20 field needs better discussion of its security properties. In particular,= =20 implementors need to ensure user expectations around what happens when a= =20 message expires are properly dealt with. For example: if a user sends a=20 message which he expects to expire in one hour, there is no guarantee tha= t the=20 recipient will be unable to retrieve the message after that time. Further= , the=20 recipient device may not preclude the storage of received messages well p= ast=20 their expiration.

[Cristina] it was left as= an=20 implementor's choice how to deal with this case, hence not intended = for=20 the standard specification.=20

I'm not suggesting that= you=20 add any specification. I'm asking that you add warning that these specific= =20 security issues exist and guidance about how they might be handled. Without= =20 security guidance, the header field does not satisfy the second numbered=20 criteria listed in section 4 of RFC 5727. Unless such considerations are ad= ded,=20 then the field cannot be registered.

/a
--_000_B802D092CAFAB344B354F0977DEB71EE558AFC5494EUSAACMS0703e_-- From bo.burman@ericsson.com Mon Jul 23 06:10:32 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C08121F86DB for ; Mon, 23 Jul 2012 06:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82IWDZoFfN+8 for ; Mon, 23 Jul 2012 06:10:30 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 050E921F863C for ; Mon, 23 Jul 2012 06:10:29 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-98-500d4d44cf29 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 34.CE.07365.44D4D005; Mon, 23 Jul 2012 15:10:29 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.109]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Mon, 23 Jul 2012 15:10:29 +0200 From: Bo Burman To: "rai@ietf.org" Date: Mon, 23 Jul 2012 15:10:27 +0200 Thread-Topic: Using media stream signaling in media plane or in signaling plane (re-send) Thread-Index: Ac1o1Ickl0NznOsHTyybSNnNjNLTOQ== Message-ID: <05F760EF51FA6A4F804F9759C239313A45E750C5AD@ESESSCMS0361.eemea.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_05F760EF51FA6A4F804F9759C239313A45E750C5ADESESSCMS0361e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUyM+Jvra6rL2+AwYM5nBaftzxjdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsyFOxkLTp1lrNi9cQZzA+PitYxdjJwcEgImEgtnNrBB2GIS F+6tB7K5OIQETjFKPJvwAspZyCjx+G8PE0gVm4CGxPwdd8G6RQQUJW483MgMYrMIqEpcnfgf bJKwQJjE53tHWSBqoiXmnn/GBmHrScxs7gabwysQLrFiymdWEJtRQFbi/vd7YPXMAuISt57M Z4K4SEBiyZ7zzBC2qMTLx/+g6mUkTi36zwpRny/xonEGC8RMQYmTM5+wTGAUmoVk1CwkZbOQ lEHE9SRuTJ3CBmFrSyxb+JoZwtaVmPHvEAuy+AJG9lWMwrmJmTnp5YZ6qUWZycXF+Xl6xamb GIFRcXDLb90djKfOiRxilOZgURLn5Ura7y8kkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0fnT kfrfa9Zph0+8dWfl7123FrQ+uqRxwsInj/VcSsMz+0l/F/68sVr14EL3ezfFM65P/yP52sz5 ftjt1gVPZNheTPedOuXruUVvbTxiHnxieqjj2xn4yNo7eNXRef0bq9wc/FlEtyaf+n1p5XlP u74/d5q8ry6y7nPOjn1pOeXznVjuvkMzDsgrsRRnJBpqMRcVJwIAyOSneVgCAAA= Subject: [RAI] Using media stream signaling in media plane or in signaling plane (re-send) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 13:10:32 -0000 --_000_05F760EF51FA6A4F804F9759C239313A45E750C5ADESESSCMS0361e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As part of the comments during IETF 83 on the following drafts * Media Stream Selection (https://datatracker.ietf.org/doc/draft-westerlund= -dispatch-stream-selection/) * PAUSE / RESUME (https://datatracker.ietf.org/doc/draft-westerlund-avtext-= rtp-stream-pause/) * Codec Operation Point (https://datatracker.ietf.org/doc/draft-westerlund-= avtext-codec-operation-point/) there was a discussion on the reasons to use one technology or the other fo= r signaling related to specific media streams. The community was lacking kn= owledge of the performance implications coming from transporting informatio= n using a specific technology, and wanted a discussion on this mailing list= . I want to provide input to this discussion and have performed a comparison = between using RTCP and using SIP as signaling technology for a particular p= urpose. I chose, more or less arbitrarily, this purpose to be sending a "PA= USE" command from a media receiver to a media sender for a specific RTP med= ia stream (identified by SSRC). Very briefly, these are the results (extracts from Section 5.1 of PAUSE / R= ESUME draft above, where more detailed descriptions of pre-conditions and a= ssumptions can be found): The targeted topology is outlined in the following figure. Provider A's network . Provider B's network . +-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+ |Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy| +-----+ +------+ +-------+ . +-------+ +-----+ ^ ^ . ^ | | SIP/H.248 . | | v . | SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP | | | MCU |<---->| BGW A |<--.-->| BGW B | | | +-----+ +-------+ . +-------+ | v ^ . ^ v +------+ / RTCP . \ RTCP +------+ | UA A |<---+ . +------>| UA B | +------+ . +------+ In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS is an Application Server, MCU is a Multipoint Conference Unit, SGW a Signaling GateWay, and BGW a media Border GateWay. ... As a partial result, the message sizes can be compared, based on the messages defined in this specification (Section 8) and a SIP UPDATE with contents (Section 10) as discussed above. Favorable and unfavorable message sizes are presented as stacked bars in the figure below. Message sizes include IPv4 headers but no lower layer data, are rounded to the nearest 25 bytes, and the bars are to scale. 250 500 750 1000 1250 1500 [byte] +---------+---------+---------+---------+---------+---------+--> Size | +-+--+ | |50| 125 RTCP +-+--+---------------+--------------------------------------------+ | SIP | 525 1650 | +--------------------+--------------------------------------------+ | ... Favorable RTCP size comes from using non-compound RTCP packets. Favorable SIP size comes from using dynamic SIP SigComp. ... The signaling delay results of the study are summarized in the following two figures. Favorable and unfavorable values are presented as stacked bars. Since there are many factors that impact the calculations, including some random processes, there are uncertainty in the calculations and delay values are thus rounded to nearest 5 ms. The bars are to scale. 50 100 150 200 250 300 [ms] +---------+---------+---------+---------+---------+---------+---> t | | Wireless UA to Wireless UA +---------------------+--------------------------------------+ | SIP | 110 | 305 +-----+---------------+-----------------------------+--------+ |RTCP | 30 | 260 +-----+---------------------------------------------+ | | Wireless UA to MCU +-------------+--+ | SIP |70| 85 +----+--------+--+--------------------------+ |RTCP| 25 | 225 +----+--------------------------------------+ | | MCU to Wireless UA +--------------+-----------------------------------+ | SIP | 75 | 255 +---+----------+------------------------------+----+ | | 20 RTCP | 230 +---+-----------------------------------------+ | ... It should be noted that RTCP scheduling above is based on a 200 kbps media = stream, leaving only 10 kbps (5%) for RTCP traffic, even for the favorable = case. Should the media stream instead be 1000 kbps (50 kbps RTCP), the unfa= vorable RTCP delays will be reduced from 260 ms to 115 ms for Wireless-Wire= less, from 225 ms to 80 ms for Wireless-MCU, and from 230 ms to 80 ms for M= CU-Wireless. ... Below are the same cases for fixed access depicted. Although delays are generally shorter, scales are kept the same for easy comparison with the previous figure. 50 100 150 200 250 300 [ms] +---------+---------+---------+---------+---------+---------+---> t | | Fixed UA to Fixed UA +------------+ | SIP | 65 +----+-------+---------------------------+ |RTCP| 25 | 205 +----+-----------------------------------+ | | Fixed UA to MCU +---------+ | SIP | 50 +---+-----+-----------------------+ | | 15 RTCP | 200 +---+-----------------------------+ | | MCU to Fixed UA +---------+ | SIP | 50 +---+-----+-----------------------+ | | 15 RTCP | 200 +---+-----------------------------+ | As can be seen, there is no obvious winner in all cases. RTCP is definitely= more compact, even when using SIP SigComp. Regarding response time, RTCP i= s more beneficial unless it is subject to unfavorable scheduling rules, too= low bandwidth, or both, in which case SIP can perform better. This rises further questions to be able to make an informed choice: * Are there other, general, reasons or recommendations that should be taken into account when choosing signaling technology? * What should the signaling strategy be when there are multiple nodes that need the signaled information, possibly not being in the direct route between the signaling peers? My own conclusion is that I would prefer using RTCP for this type of media = stream-related signaling, since: * The media stream-related signaling does not have any major impact on the session itself, only what can be considered normal in-session variations, and thus there should be no need to notify all session- handling functions via SIP * All media-handling nodes are already in the media path and will automatically have access to this new signaling, but may of course have to implement support for it if they need to act on it * The difference in signaling bandwidth is definitely in RTCP's favor * The RTCP signaling delay has a clear potential to be lower than SIP and it should already be possible to configure RTCP such that this low delay can be achieved in a large majority of cases Comments on the above are greatly appreciated! Cheers, Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- --_000_05F760EF51FA6A4F804F9759C239313A45E750C5ADESESSCMS0361e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As part of the comments during IETF 83 on the following drafts

* Media Stream Selection (htt= ps://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection/)

* PAUSE / RESUME (https://datat= racker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/)

* Codec Operation Point (h= ttps://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-poi= nt/)

there was a discussion on the reasons to use one technology or the oth= er for signaling related to specific media streams. The community was lacki= ng knowledge of the performance implications coming from transporting infor= mation using a specific technology, and wanted a discussion on this mailing list.

I want to provide input to this discussion and have performed a compar= ison between using RTCP and using SIP as signaling technology for a particu= lar purpose. I chose, more or less arbitrarily, this purpose to be sending = a "PAUSE" command from a media receiver to a media sender for a specific RTP media stream (identified by SSRC).

Very briefly, these are the results (extracts from Section 5.1 of PAUS= E / RESUME draft above, where more detailed descriptions of pre-conditions = and assumptions can be found):

The targeted topology is outlined in the following figure= .

&nbs= p; Provider A's network . Provide= r B's network

&nbs= p; &= nbsp; &nbs= p; .

+-----+ SIP +------+ SIP +-------+= ; SIP +-------+ SIP +-----+

|Proxy|<--->| AS A |<--->| SGW A |<--.--&g= t;| SGW B |<--->|Proxy|

+-----+ +------+&= nbsp; +-------+ . +--= -----+ +-----+

^ &n= bsp; ^ &nb= sp; .&nbs= p; &= nbsp; ^

| &n= bsp; | SIP/H.248 = ; . = |

| &n= bsp; v &nb= sp; .&nbs= p; &= nbsp; |

SIP | +-----+= RTCP +-------+ RTCP +-------+ SIP = |

| &n= bsp; | MCU |<---->| BGW A |<--.-->| BGW B | &n= bsp; |

| &n= bsp; +-----+ +-------+ &= nbsp; . +-------+ &n= bsp; |

v &n= bsp; ^ &nb= sp; .&nbs= p; ^ = ; v

+------+ / RTCP &nbs= p; &= nbsp; . \ RTCP&= nbsp; +------+

| UA A |<---+ &= nbsp; &nbs= p; . = ; +------>| UA B |

+------+ = ; &n= bsp; . &nb= sp; = +------+

In the figure above, UA is a SIP User Agent, Proxy is a S= IP Proxy, AS

is an Application Server, MCU is a Multipoint Conference = Unit, SGW a

Signaling GateWay, and BGW a media Border GateWay.

...

As a partial result, the message sizes can be compared, b= ased on the

messages defined in this specification (Section 8) and a = SIP UPDATE

with contents (Section 10) as discussed above. Favo= rable and

unfavorable message sizes are presented as stacked bars i= n the figure

below. Message sizes include IPv4 headers but no lo= wer layer data,

are rounded to the nearest 25 bytes, and the bars are to = scale.

250= 500 = ; 750 1000 1250= 1500 [byte]

+---------+---------+---------+---------&= #43;---------+---------+--> Size

+-+--+

| |50| 125 RTCP

+-+--+---------------+-------------------= -------------------------+

| SIP &nbs= p; | 525 &= nbsp; &nbs= p; &= nbsp; 1650 |

+--------------------+---------------------------= -----------------+

...

Favorable RTCP size comes from using non-compound RTCP packets.

Favorable SIP size comes from using dynamic SIP SigComp.

...

The signaling delay results of the study are summarized i= n the

following two figures. Favorable and unfavorable va= lues are

presented as stacked bars. Since there are many fac= tors that impact

the calculations, including some random processes, there = are

uncertainty in the calculations and delay values are thus= rounded to

nearest 5 ms. The bars are to scale.

&nbs= p; 50 100 = 150 200 &= nbsp; 250 300 [ms]

+---------+---------+---------+---------&= #43;---------+---------+---> t

| Wireless UA to Wireless UA

+---------------------+--------------------------= ------------+

| SIP &nbs= p; | 110 &= nbsp; &nbs= p; &= nbsp; | 305

+-----+---------------+----------------------= -------+--------+

|RTCP | 30 = ; &n= bsp; = ; | 260

+-----+------------------------------------------= ---+

| Wireless UA to MCU

+-------------+--+

| SIP |70= | 85

+----+--------+--+-----------------------= ---+

|RTCP| 25 = &nb= sp; = | 225

+----+--------------------------------------+=

| MCU to Wireless UA

+--------------+---------------------------------= --+

| SIP &nbs= p; | 75 &n= bsp; = ; | 255

+---+----------+-----------------------------= -+----+

| | 20 RTCP &nbs= p; &= nbsp; &nbs= p; | 230

+---+-----------------------------------------= 3;

...

It should be noted that RTCP scheduling above is based on a 200 kbps m= edia stream, leaving only 10 kbps (5%) for RTCP traffic, even for the favor= able case. Should the media stream instead be 1000 kbps (50 kbps RTCP), the= unfavorable RTCP delays will be reduced from 260 ms to 115 ms for Wireless-Wireless, from 225 ms to 80 ms f= or Wireless-MCU, and from 230 ms to 80 ms for MCU-Wireless.

...

Below are the same cases for fixed access depicted. = Although delays

are generally shorter, scales are kept the same for easy = comparison

with the previous figure.

&nbs= p; 50 100 = 150 200 &= nbsp; 250 300 [ms]

+---------+---------+---------+---------&= #43;---------+---------+---> t

| Fixed UA to Fixed UA

+------------+

| SIP | 65

+----+-------+---------------------------+= ;

|RTCP| 25 = &nb= sp; | 205

+----+-----------------------------------+

| Fixed UA to MCU

+---------+

| SIP | 50

+---+-----+-----------------------+

| | 15 RTCP &nbs= p; &= nbsp; | 200

+---+-----------------------------+

| MCU to Fixed UA

+---------+

| SIP | 50

+---+-----+-----------------------+

| | 15 RTCP &nbs= p; &= nbsp; | 200

+---+-----------------------------+

As can be seen, there is no obvious winner in all cases. RTCP is defin= itely more compact, even when using SIP SigComp. Regarding response time, R= TCP is more beneficial unless it is subject to unfavorable scheduling rules= , too low bandwidth, or both, in which case SIP can perform better.

This rises further questions to be able to make an informed choice:

* Are there other, general, reasons or recommendations that should

be taken into account when choosing signaling technology?

* What should the signaling strategy be when there are multiple nodes<= /div>

that need the signaled information, possibly not being in the d= irect

route between the signaling peers?

My own conclusion is that I would prefer using RTCP for this type of m= edia stream-related signaling, since:

* The media stream-related signaling does not have any major impact on=

the session itself, only what can be considered normal in-sessi= on

variations, and thus there should be no need to notify all sess= ion-

handling functions via SIP

* All media-handling nodes are already in the media path and will

automatically have access to this new signaling, but may of cou= rse

have to implement support for it if they need to act on it

* The difference in signaling bandwidth is definitely in RTCP's favor<= /div>

* The RTCP signaling delay has a clear potential to be lower than SIP<= /div>

and it should already be possible to configure RTCP such that t= his

low delay can be achieved in a large majority of cases

Comments on the above are greatly appreciated!

Cheers,

Bo Burman

----------------------------------------------------------------------=

Multimedia Technologies, Ericsson Research EAB/TVM

----------------------------------------------------------------------=

Ericsson AB = ; | Phone +46 10 7141311

F=E4r=F6gatan 6 &= nbsp; | Mobile +46 73 0949021

SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com

----------------------------------------------------------------------=

--_000_05F760EF51FA6A4F804F9759C239313A45E750C5ADESESSCMS0361e_-- From pkyzivat@alum.mit.edu Mon Jul 23 07:32:27 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEF1911E807F for ; Mon, 23 Jul 2012 07:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, J_CHICKENPOX_55=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re0gsJDsCLuD for ; Mon, 23 Jul 2012 07:32:27 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id C035D11E8086 for ; Mon, 23 Jul 2012 07:32:26 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id dnZ61j00B1ap0As53qYVgn; Mon, 23 Jul 2012 14:32:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id dqYg1j00L3ZTu2S3iqYgxJ; Mon, 23 Jul 2012 14:32:41 +0000 Message-ID: <500D6079.9050909@alum.mit.edu> Date: Mon, 23 Jul 2012 10:32:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: rai@ietf.org References: <05F760EF51FA6A4F804F9759C239313A45E750C5AD@ESESSCMS0361.eemea.ericsson.se> In-Reply-To: <05F760EF51FA6A4F804F9759C239313A45E750C5AD@ESESSCMS0361.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [RAI] Using media stream signaling in media plane or in signaling plane (re-send) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 14:32:27 -0000 Bo, Did you consider the implications if there is more than one stream to be paused? (E.g. it's an audio+video call.) Presumably that would double the message traffic when done in the media streams, but not when done in sip. (But the absolute delays may be no different.) Thanks, Paul On 7/23/12 9:10 AM, Bo Burman wrote: > As part of the comments during IETF 83 on the following drafts > * Media Stream Selection > (_https://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection/_) > * PAUSE / RESUME > (_https://datatracker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/_) > * Codec Operation Point > (_https://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-point/_) > there was a discussion on the reasons to use one technology or the other > for signaling related to specific media streams. The community was > lacking knowledge of the performance implications coming from > transporting information using a specific technology, and wanted a > discussion on this mailing list. > I want to provide input to this discussion and have performed a > comparison between using RTCP and using SIP as signaling technology for > a particular purpose. I chose, more or less arbitrarily, this purpose to > be sending a "PAUSE" command from a media receiver to a media sender for > a specific RTP media stream (identified by SSRC). > Very briefly, these are the results (extracts from Section 5.1 of PAUSE > / RESUME draft above, where more detailed descriptions of pre-conditions > and assumptions can be found): > The targeted topology is outlined in the following figure. > Provider A's network . Provider B's network > . > +-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+ > |Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy| > +-----+ +------+ +-------+ . +-------+ +-----+ > ^ ^ . ^ > | | SIP/H.248 . | > | v . | > SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP | > | | MCU |<---->| BGW A |<--.-->| BGW B | | > | +-----+ +-------+ . +-------+ | > v ^ . ^ v > +------+ / RTCP . \ RTCP +------+ > | UA A |<---+ . +------>| UA B | > +------+ . +------+ > In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS > is an Application Server, MCU is a Multipoint Conference Unit, SGW a > Signaling GateWay, and BGW a media Border GateWay. > ... > As a partial result, the message sizes can be compared, based on the > messages defined in this specification (Section 8) and a SIP UPDATE > with contents (Section 10) as discussed above. Favorable and > unfavorable message sizes are presented as stacked bars in the figure > below. Message sizes include IPv4 headers but no lower layer data, > are rounded to the nearest 25 bytes, and the bars are to scale. > 250 500 750 1000 1250 1500 [byte] > +---------+---------+---------+---------+---------+---------+--> Size > | > +-+--+ > | |50| 125 RTCP > +-+--+---------------+--------------------------------------------+ > | SIP | 525 1650 | > +--------------------+--------------------------------------------+ > | > ... > Favorable RTCP size comes from using non-compound RTCP packets. > Favorable SIP size comes from using dynamic SIP SigComp. > ... > The signaling delay results of the study are summarized in the > following two figures. Favorable and unfavorable values are > presented as stacked bars. Since there are many factors that impact > the calculations, including some random processes, there are > uncertainty in the calculations and delay values are thus rounded to > nearest 5 ms. The bars are to scale. > 50 100 150 200 250 300 [ms] > +---------+---------+---------+---------+---------+---------+---> t > | > | Wireless UA to Wireless UA > +---------------------+--------------------------------------+ > | SIP | 110 | 305 > +-----+---------------+-----------------------------+--------+ > |RTCP | 30 | 260 > +-----+---------------------------------------------+ > | > | Wireless UA to MCU > +-------------+--+ > | SIP |70| 85 > +----+--------+--+--------------------------+ > |RTCP| 25 | 225 > +----+--------------------------------------+ > | > | MCU to Wireless UA > +--------------+-----------------------------------+ > | SIP | 75 | 255 > +---+----------+------------------------------+----+ > | | 20 RTCP | 230 > +---+-----------------------------------------+ > | > ... > It should be noted that RTCP scheduling above is based on a 200 kbps > media stream, leaving only 10 kbps (5%) for RTCP traffic, even for the > favorable case. Should the media stream instead be 1000 kbps (50 kbps > RTCP), the unfavorable RTCP delays will be reduced from 260 ms to 115 ms > for Wireless-Wireless, from 225 ms to 80 ms for Wireless-MCU, and from > 230 ms to 80 ms for MCU-Wireless. > ... > Below are the same cases for fixed access depicted. Although delays > are generally shorter, scales are kept the same for easy comparison > with the previous figure. > 50 100 150 200 250 300 [ms] > +---------+---------+---------+---------+---------+---------+---> t > | > | Fixed UA to Fixed UA > +------------+ > | SIP | 65 > +----+-------+---------------------------+ > |RTCP| 25 | 205 > +----+-----------------------------------+ > | > | Fixed UA to MCU > +---------+ > | SIP | 50 > +---+-----+-----------------------+ > | | 15 RTCP | 200 > +---+-----------------------------+ > | > | MCU to Fixed UA > +---------+ > | SIP | 50 > +---+-----+-----------------------+ > | | 15 RTCP | 200 > +---+-----------------------------+ > | > As can be seen, there is no obvious winner in all cases. RTCP is > definitely more compact, even when using SIP SigComp. Regarding response > time, RTCP is more beneficial unless it is subject to unfavorable > scheduling rules, too low bandwidth, or both, in which case SIP can > perform better. > This rises further questions to be able to make an informed choice: > * Are there other, general, reasons or recommendations that should > be taken into account when choosing signaling technology? > * What should the signaling strategy be when there are multiple nodes > that need the signaled information, possibly not being in the direct > route between the signaling peers? > My own conclusion is that I would prefer using RTCP for this type of > media stream-related signaling, since: > * The media stream-related signaling does not have any major impact on > the session itself, only what can be considered normal in-session > variations, and thus there should be no need to notify all session- > handling functions via SIP > * All media-handling nodes are already in the media path and will > automatically have access to this new signaling, but may of course > have to implement support for it if they need to act on it > * The difference in signaling bandwidth is definitely in RTCP's favor > * The RTCP signaling delay has a clear potential to be lower than SIP > and it should already be possible to configure RTCP such that this > low delay can be achieved in a large majority of cases > Comments on the above are greatly appreciated! > Cheers, > Bo Burman > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7141311 > F�r�gatan 6 | Mobile +46 73 0949021 > SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com > ---------------------------------------------------------------------- > > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From magnus.westerlund@ericsson.com Tue Jul 24 00:08:28 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEB011E811C for ; Tue, 24 Jul 2012 00:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.902 X-Spam-Level: X-Spam-Status: No, score=-105.902 tagged_above=-999 required=5 tests=[AWL=-0.253, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_55=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-ZVZc8-OREl for ; Tue, 24 Jul 2012 00:08:28 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD1A11E8119 for ; Tue, 24 Jul 2012 00:08:27 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-cb-500e49e903ad Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id A3.A6.07365.9E94E005; Tue, 24 Jul 2012 09:08:25 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.0; Tue, 24 Jul 2012 09:08:25 +0200 Message-ID: <500E49E8.3050708@ericsson.com> Date: Tue, 24 Jul 2012 09:08:24 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Paul Kyzivat References: <05F760EF51FA6A4F804F9759C239313A45E750C5AD@ESESSCMS0361.eemea.ericsson.se> <500D6079.9050909@alum.mit.edu> In-Reply-To: <500D6079.9050909@alum.mit.edu> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUyM+Jvre5LT74Ag1/TjS1WbDjAavF5yzNW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSuj401ZwWehiiUfT7M2MC7n72Lk5JAQMJFo Ob6CCcIWk7hwbz1bFyMXh5DAKUaJaz9nMkE4yxkl3v+5xghSxSugLXFx7kk2EJtFQFViwZp2 sDibgIXEzR+NYHFRgUCJb1uPs0LUC0qcnPmEpYuRg0NEQENi0lY1kDCzgKLE0wnbwFqFBRIk 5nW2gdlCAuUSJw49AmvlFNCReLC4lQmkVUJAUuL2gRSIVj2JKVdbGCFseYnmrbOZIVq1JRqa OlgnMArNQrJ4FpKWWUhaFjAyr2IUzk3MzEkvN9RLLcpMLi7Oz9MrTt3ECAzfg1t+6+5gPHVO 5BCjNAeLkjgvV9J+fyGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M3g8XWRsk+q5zPX5O+tc+ s4hvRnx7ut7WOT7aedf/VfXrl0+rFf1nqvQu/uB+4eUsu4RdV65lN8Z7SD87KHZXhU+BRYZH aqdp3qxCdcnEdM+nut/0xWMaZ3nEewV8/y5X+/N0V5L3SoNb7PsP/fzCO7+2NH1mxqU6yWU8 B8N/9u2dejXBbbGtEktxRqKhFnNRcSIANawISy0CAAA= Cc: "rai@ietf.org" Subject: Re: [RAI] Using media stream signaling in media plane or in signaling plane (re-send) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jul 2012 07:08:28 -0000 On 2012-07-23 16:32, Paul Kyzivat wrote: > Bo, > > Did you consider the implications if there is more than one stream to be > paused? (E.g. it's an audio+video call.) > > Presumably that would double the message traffic when done in the media > streams, but not when done in sip. (But the absolute delays may be no > different.) Paul, When it comes to multiple streams it will highly depend on if the different streams belong to the same RTP session or not. If they are within the same RTP session the RTCP based method will add one more FCI block per SSRC, i.e. for a PAUSE or resume request 8 more bytes. And for example you can pause one SSRC and resume another with the same RTCP packet. If they are from different RTP sessions then different RTCP packets will be required. Thus you get different scheduling of the request packet and clearly two RTCP packets bringing up the overhead a bit, to at worst case a minimal compound RTCP packet, i.e. around 120-140 bytes depending on CNAME length. It will take at least 5-10 RTP sessions being simultaneously manipulated using RTCP to have approximately the same aggregated size as using SIP. I think the main question around this direction of discussion if any application has very strict requirements on having atomic operations between RTP sessions. I personally haven't seen any such case. And Paul's example of audio and video being paused may not be the best although in no way prohibited. But one common usage we see for this is to pause the video stream that is responsible for the larger amount of data while keeping the audio running to a RTP mixer. Then have that mixer base its decision on what video streams it provides the other session participants based on the audio activity. There might be cases where pausing both audio and video simultaneously is a reasonable usage, and if you have a more concrete example I would appreciate it. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F�r�gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From davids@iit.edu Mon Jul 16 12:09:19 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8271011E82F3 for ; Mon, 16 Jul 2012 12:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.392 X-Spam-Level: X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hT48+vTf7gw for ; Mon, 16 Jul 2012 12:09:19 -0700 (PDT) Received: from spamblock-1.iit.edu (spamblock-1.iit.edu [216.47.143.127]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8E411E82EF for ; Mon, 16 Jul 2012 12:09:19 -0700 (PDT) X-ASG-Debug-ID: 1342465799-03d9b5362c4f0de0001-uZpzFd Received: from atlas-v-iv.iit.edu (atlas-p.iit.edu [216.47.143.155]) by spamblock-1.iit.edu with ESMTP id RYMMyAP2CKRXHDB5; Mon, 16 Jul 2012 14:09:59 -0500 (CDT) X-Barracuda-Envelope-From: davids@iit.edu X-Barracuda-Apparent-Source-IP: 216.47.143.155 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII Received: from [192.168.0.197] (c-67-184-3-189.hsd1.il.comcast.net [67.184.3.189]) by atlas-v.iit.edu (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTPA id <0M7900K19P9VVS50@atlas-v.iit.edu>; Mon, 16 Jul 2012 14:10:48 -0500 (CDT) User-Agent: Microsoft-MacOutlook/14.2.3.120616 Date: Mon, 16 Jul 2012 14:09:54 -0500 From: Carol Davids X-ASG-Orig-Subj: Re: [bmwg] RAI-ART review of draft-ietf-bmwg-sip-bench-term-04 and draft-ietf-bmwg-sip-bench-meth-04 To: "Worley, Dale R (Dale)" , "rai@ietf.org" , Al Morton , "draft-ietf-bmwg-sip-bench-term@tools.ietf.org" , "bmwg@ietf.org" Message-id: Thread-topic: [bmwg] RAI-ART review of draft-ietf-bmwg-sip-bench-term-04 and draft-ietf-bmwg-sip-bench-meth-04 In-reply-to: X-Barracuda-Connect: atlas-p.iit.edu[216.47.143.155] X-Barracuda-Start-Time: 1342465799 X-Barracuda-URL: http://216.47.143.127:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at iit.edu X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=7.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.102890 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header X-Mailman-Approved-At: Tue, 24 Jul 2012 06:34:22 -0700 Subject: Re: [RAI] [bmwg] RAI-ART review of draft-ietf-bmwg-sip-bench-term-04 and draft-ietf-bmwg-sip-bench-meth-04 X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 19:09:19 -0000 Dale, Thanks very much for your careful review of the drafts. Please see below for our responses and descriptions of what we have done to address the issues. We highlight your comments under RAI-ART REVIEW COMMENT:, and indicate our responses under RESPONSE:CD/VG: We also appreciate your pointing out the need for a final editorial review and have begun that work using the detail you provided. We plan to post the edited version in time for IETF 85 in November. Best, Carol Carol Davids Email: davids@iit.edu Skype: caroldavids1 .................................................................. RAI-ART REVIEW COMMENT: I. Technical issues A. Media The drafts seem to be undecided as to whether they want to benchmark media processing or not. At one point, it says that the benchmarking is entirely in the signaling plane. At another point, it is specified how to set the number of media streams per INVITE dialog. I suspect the conflict is that there are devices the WG wants to benchmark which do handle the media and their media handling affects performance significantly, but the WG is unsure how to parametrize media benchmarking. RESPONSE: CD/VG: The media parameters need to be specified because, if the DUT/SUT processes media, the media processing will impact the SIP Performance, using cycles that could otherwise have been used for SIP-related processing. We do not measure the performance of the audio and/or video. But we need to document the conditions under which the test was conducted if we are to be able to compare test results. We are measuring the signaling-plane throughput, but thisthroughput will vary depending upon the conditions of test. One important condition of test is media processing: Is the DUT processing media streams and if so, how many and what parameters define them? We note the presence and character of the media streams being processed by the device without measuring the quality of the resulting media. We define the the media according to the packet size, type of codec, and number of streams. These parameters describe the conditions under which the test is performed. But we do not measure the quality or other characteristics of the resulting media. We expect that the more work we ask the device under test to do, the lower will be its SIP throughput. RAI-ART REVIEW COMMENT: The simplest situation, of course, is if the DUT is a proxy and the media bypasses it entirely. Beyond that, even in the simplest media relaying situations, significant processing costs can arise. Even if the DUT isn't transcoding, it may have to rewrite the RTP codec numbers (as it may have modified the SDP passing through it). In more complex situations, the DUT may have to transcode the codecs. Some consideration has to be made of how to specify exactly what the media loads are. SDP already has ways to specify the exact encoding of media streams, including the number of samples per packet, which implies the packet size and packet rate. These drafts only allow specifying the packet size as a benchmark parameter, but packet size is notoriously ambiguous -- which layers of encapsulation of the encoded media are counted? But specifying the detailed encoding side-steps that question. RESPONSE:CD/VG: We will add a note that the testing organization may choose to specify more characteristics of the associated media and may keep records of comparative results. Our goal in this draft is to describe a method for measuring SIP throughput of the device under test. Organizations are encouraged to identify boundary conditions that they deem important and to perform tests under as many variants of these boundary conditions as they wish. RAI-ART REVIEW COMMENT: The draft wants to consider the duration of a media stream to be separately adjustable from the duration of the containing dialog, but the draft explicitly places out of scope the re-INVITE which is necessary to accomplish that realistically (that is, with the signaling matching the presented media packets). RESPONSE:CD/VG: The parameters of test are recorded in the test setup report. The session attempt rate and the total number of sessions to be attempted are identified in this report. These two numbers determine the total length of the test. The duration of a session is also identified in this report, but the name we assigned that parameter is "Media session hold time." We will change the name of the parameter to "Session hold time." When the INVITE-initiated session includes media, then the session hold time represents the duration of the media session. Whether or not we include media, the session ends when the BYE message is received by the emulated agent. We do not include the duration of a stream among the parameters of test. We do allow there to be multiple media streams per session, but the session is ended by a BYE. Re-INVITEs are a different question. They do not affect the duration of the session. But it is true that they consume processing cycles. We will discuss this further and appreciate your identifying the issue. We will also add a test parameter that describes the time between successive call attempts by the emulated agent. We recommend setting this parameter to 0 since setting it at a higher value will make the testing-to-failure take longer. RAI-ART REVIEW COMMENT: B. INVITE dialog structure The drafts seem to want to consider the establishment (or failure thereof) of an INVITE dialog to be instantaneous, after which the dialog continues for a chosen length of time, and then vanishes instantly. Little or no consideration is given to the various scenarios of call establishment, including the most common case: INVITE sent -- 183 response -- significant delay -- 200 response. Dialog teardown is not conceptualized as being a processing step that involves significant cost and may fail: "Session disconnect is not considered in the scope of this work item." This lack of consideration is enhanced in the forking cases, as the variety of scenarios (and their durations) increases. In addition, the drafts only consider forking which is done within the DUT, whereas it will be common in practice for forking to be done downstream of the DUT, presenting the DUT with a stream of 1xx responses from multiple endpoints, with a 2xx after an extended delay. Also, in regard to signaling benchmarking, INVITEs that ultimately fail are likely to be as costly as INVITEs that succeed, but there doesn't seem to be a defined parameter "fraction of attempted calls which succeed" (which controls the callee EAs). RESPONSE:CD/VG: RE DELAY: The delay in responding with a 200 OK after getting an INVITE is not specified in the current methodology document and is assumed to be instantaneous. Our intent is to stress the DUT as quickly as possible. Introducing a delay serves to increase the time before the DUT produces its first stress-induced error. A high interval (> 32s) may cause the DUT to enter a stable state and not be subject to stress. For this reason, we intentionally chose not to introduce delays before issuing a 200 OK. Note that many user agents automatically introduce delays by first sending a 180-ringing, etc. Any additional artificial delays, while easy to introduce, would be an additional tuning parameter that is subject to differing interpretations. RE FORKING: Regarding the forking case being done in the DUT --- this was a design choice since we wanted to model the complexity and delay caused by forking N branches downstream and collating the responses, etc. at the DUT. In other words, our assumption is that the DUT is a proxy (or a B2BUA) and is doing forking and response collating. The event that the tester arranges forking to happen downstream of the DUT is automatically captured when the device acting as a DUT is a user agent client and the next downstream SIP entity is forking and presenting responses to the DUT. RE THE COST OF FAILURES: Regarding the contention that "INVITEs that ultimately fail are likely to be as costly as INVITEs that succeed, but there doesn't seem to be a Defined parameter "fraction of attempted calls which succeed" (which controls the callee EAs)" --- it seems to us that the Session Establishment Performance benchmark (please see Section 5.2) covers this. RAI-ART REVIEW COMMENT: C. Loop detection All discussions of loop detection needs to based on the revised loop detection requirements in RFC 5393. RESPONSE:CD/VG: We will update the methodology document to ensure that loop detection is based on the revised loop detection requirements in rfc5393. This is a good catch! RAI-ART REVIEW COMMENT: D. Authentication In some SIP operations, authentication is commonly done. This can have various effects on the message flows that need to be taken into account in the benchmarks. For instance, a registrar may require that the registering UA authenticate itself. Commonly, the UA sends a REGISTER request, which is rejected with 401 because it contains a nonce that is too old. The UA then immediately sends another REGISTER with the nonce provided in the 401 response, and that request receives a 200 response. In this scenario, the number of effective REGISTER requests is half of the total REGISTER requests, leading to an apparent attempt failure rate of 50%, even though the middlebox is doing the Right Thing 100% of the time. This suggests that the definition of "attempt failure" needs to be updated so that a 4xx response "passed upstream" by the DUT is not counted as an attempt failure. In other scenarios, the DUT itself might be expected to enforce SIP authentication, which would require a somewhat different definition of attempt failure, and would be expected to have lower throughput. So some thought needs to be given as to whether these scenarios are to be benchmarked, and to document how authentication is to be handle in whatever benchmarks are defined. RESPONSE:CD/VG: We agree with your analysis, and in fact, the terminology document already recognizes this through its scope (please see Section 2.1 of the terminology document). It says, o REGISTER and INVITE requests may be challenged or remain unchallenged for authentication purpose as this may impact the performance benchmarks. Any observable performance degradation due to authentication is of interest to the SIP community. Whether or not the REGISTER and INVITE requests are challenged is a condition of test and will be recorded and reported. However, in the methodology document, we do not include any further guidance for this. As you point out, there is a need for some guidance. To remedy this, we propose that we add the following in Section 5.1 of The methodology document: Authentication option = ___________________________________ (on|off; if on, please see Note-2 below). Number of responses of the following type: 401: _____________ (if authentication turned on; N/A otherwise) 407: _____________ (if authentication turned on; N/A otherwise) 2xx-class: _____________ 1xx-class: _____________ Others: _____________ This information will provide the tester to analyze how many 401/407 were received and adjust the metrics in Section 5.2 and 5.3 accordingly. > From bo.burman@ericsson.com Mon Jul 23 06:06:04 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8166F21F863B for ; Mon, 23 Jul 2012 06:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvM8jFcloWpU for ; Mon, 23 Jul 2012 06:06:03 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3931C21F85CE for ; Mon, 23 Jul 2012 06:06:02 -0700 (PDT) X-AuditID: c1b4fb2d-b7f6c6d000001cc5-d6-500d4c39d1dd Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 17.2E.07365.93C4D005; Mon, 23 Jul 2012 15:06:01 +0200 (CEST) Received: from ESESSCMS0361.eemea.ericsson.se ([169.254.1.109]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 23 Jul 2012 15:06:01 +0200 From: Bo Burman To: "rai@ietf.org" Date: Mon, 23 Jul 2012 15:06:00 +0200 Thread-Topic: Using media stream signaling in media plane or in signaling plane Thread-Index: Ac1o0+fkEiKVhUZDQKKJOvv4nrECQg== Message-ID: <05F760EF51FA6A4F804F9759C239313A45E750C5A0@ESESSCMS0361.eemea.ericsson.se> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: sv-SE, en-US Content-Type: multipart/alternative; boundary="_000_05F760EF51FA6A4F804F9759C239313A45E750C5A0ESESSCMS0361e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+Jvra6lD2+Awclv4haftzxjdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuvNrywF988yVhzZtY6tgXHLWsYuRk4OCQETiZVzZ0LZYhIX 7q1n62Lk4hASOMUoseHNUVYIZy6jxLqfj9hAqtgENCTm77gL1iEioChx4+FGZhCbRUBVYuux bnYQW1jAS+L+oX6gZg6gmkCJD7+EIMr1JO7/fA3WyisQLvHifCfYSEYBWYn73++xgNjMAuIS t57MZ4I4SEBiyZ7zzBC2qMTLx/9YIeplJE4t+s8KUZ8vcfJGFxPETEGJkzOfsExgFJqFZNQs JGWzkJRBxPUkbkydwgZha0ssW/iaGcLWlZjx7xALsvgCRvZVjMK5iZk56eWGeqlFmcnFxfl5 esWpmxiBMXFwy2/dHYynzokcYpTmYFES5+VK2u8vJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gdHrVkbmuuMz5uY1JvkaMvbKGp58GRfwdXeqV175Ua3k10++Wjd32GUVpZXt8cpaorle6Lpi ndx0MTPehLJrrzk+ZtjOK5lconbeXiV9X+nur1eY7j6Lmd9WxnMtoEkmO2PV4e7Zff9X1Oxp 0VqqYvfq4pKoRSImL+9zzJt56ep3tnm2xzvTBZVYijMSDbWYi4oTAQImScNXAgAA X-Mailman-Approved-At: Tue, 24 Jul 2012 06:34:22 -0700 Subject: [RAI] Using media stream signaling in media plane or in signaling plane X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2012 13:06:04 -0000 --_000_05F760EF51FA6A4F804F9759C239313A45E750C5A0ESESSCMS0361e_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As part of the comments during IETF 83 on the following drafts * Media Stream Selection (https://datatracker.ietf.org/doc/draft-westerlund= -dispatch-stream-selection/) * PAUSE / RESUME (https://datatracker.ietf.org/doc/draft-westerlund-avtext-= rtp-stream-pause/) * Codec Operation Point (https://datatracker.ietf.org/doc/draft-westerlund-= avtext-codec-operation-point/) there was a discussion on the reasons to use one technology or the other fo= r signaling related to specific media streams. The community was lacking kn= owledge of the performance implications coming from transporting informatio= n using a specific technology, and wanted a discussion on this mailing list= . I want to provide input to this discussion and have performed a comparison = between using RTCP and using SIP as signaling technology for a particular p= urpose. I chose, more or less arbitrarily, this purpose to be sending a "PA= USE" command from a media receiver to a media sender for a specific RTP med= ia stream (identified by SSRC). Very briefly, these are the results (extracts from Section 5.1 of PAUSE / R= ESUME draft above, where more detailed descriptions of pre-conditions and a= ssumptions can be found): The targeted topology is outlined in the following figure. Provider A's network . Provider B's network . +-----+ SIP +------+ SIP +-------+ SIP +-------+ SIP +-----+ |Proxy|<--->| AS A |<--->| SGW A |<--.-->| SGW B |<--->|Proxy| +-----+ +------+ +-------+ . +-------+ +-----+ ^ ^ . ^ | | SIP/H.248 . | | v . | SIP | +-----+ RTCP +-------+ RTCP +-------+ SIP | | | MCU |<---->| BGW A |<--.-->| BGW B | | | +-----+ +-------+ . +-------+ | v ^ . ^ v +------+ / RTCP . \ RTCP +------+ | UA A |<---+ . +------>| UA B | +------+ . +------+ In the figure above, UA is a SIP User Agent, Proxy is a SIP Proxy, AS is an Application Server, MCU is a Multipoint Conference Unit, SGW a Signaling GateWay, and BGW a media Border GateWay. ... As a partial result, the message sizes can be compared, based on the messages defined in this specification (Section 8) and a SIP UPDATE with contents (Section 10) as discussed above. Favorable and unfavorable message sizes are presented as stacked bars in the figure below. Message sizes include IPv4 headers but no lower layer data, are rounded to the nearest 25 bytes, and the bars are to scale. 250 500 750 1000 1250 1500 [byte] +---------+---------+---------+---------+---------+---------+--> Size | +-+--+ | |50| 125 RTCP +-+--+---------------+--------------------------------------------+ | SIP | 525 1650 | +--------------------+--------------------------------------------+ | ... Favorable RTCP size comes from using non-compound RTCP packets. Favorable SIP size comes from using dynamic SIP SigComp. ... The signaling delay results of the study are summarized in the following two figures. Favorable and unfavorable values are presented as stacked bars. Since there are many factors that impact the calculations, including some random processes, there are uncertainty in the calculations and delay values are thus rounded to nearest 5 ms. The bars are to scale. 50 100 150 200 250 300 [ms] +---------+---------+---------+---------+---------+---------+---> t | | Wireless UA to Wireless UA +---------------------+--------------------------------------+ | SIP | 110 | 305 +-----+---------------+-----------------------------+--------+ |RTCP | 30 | 260 +-----+---------------------------------------------+ | | Wireless UA to MCU +-------------+--+ | SIP |70| 85 +----+--------+--+--------------------------+ |RTCP| 25 | 225 +----+--------------------------------------+ | | MCU to Wireless UA +--------------+-----------------------------------+ | SIP | 75 | 255 +---+----------+------------------------------+----+ | | 20 RTCP | 230 +---+-----------------------------------------+ | ... It should be noted that RTCP scheduling above is based on a 200 kbps media = stream, leaving only 10 kbps (5%) for RTCP traffic, even for the favorable = case. Should the media stream instead be 1000 kbps (50 kbps RTCP), the unfa= vorable RTCP delays will be reduced from 260 ms to 115 ms for Wireless-Wire= less, from 225 ms to 80 ms for Wireless-MCU, and from 230 ms to 80 ms for M= CU-Wireless. ... Below are the same cases for fixed access depicted. Although delays are generally shorter, scales are kept the same for easy comparison with the previous figure. 50 100 150 200 250 300 [ms] +---------+---------+---------+---------+---------+---------+---> t | | Fixed UA to Fixed UA +------------+ | SIP | 65 +----+-------+---------------------------+ |RTCP| 25 | 205 +----+-----------------------------------+ | | Fixed UA to MCU +---------+ | SIP | 50 +---+-----+-----------------------+ | | 15 RTCP | 200 +---+-----------------------------+ | | MCU to Fixed UA +---------+ | SIP | 50 +---+-----+-----------------------+ | | 15 RTCP | 200 +---+-----------------------------+ | As can be seen, there is no obvious winner in all cases. RTCP is definitely= more compact, even when using SIP SigComp. Regarding response time, RTCP i= s more beneficial unless it is subject to unfavorable scheduling rules, too= low bandwidth, or both, in which case SIP can perform better. This rises further questions to be able to make an informed choice: * Are there other, general, reasons or recommendations that should be taken into account when choosing signaling technology? * What should the signaling strategy be when there are multiple nodes that need the signaled information, possibly not being in the direct route between the signaling peers? My own conclusion is that I would prefer using RTCP for this type of media = stream-related signaling, since: * The media stream-related signaling does not have any major impact on the session itself, only what can be considered normal in-session variations, and thus there should be no need to notify all session- handling functions via SIP * All media-handling nodes are already in the media path and will automatically have access to this new signaling, but may of course have to implement support for it if they need to act on it * The difference in signaling bandwidth is definitely in RTCP's favor * The RTCP signaling delay has a clear potential to be lower than SIP and it should already be possible to configure RTCP such that this low delay can be achieved in a large majority of cases Comments on the above are greatly appreciated! Cheers, Bo Burman ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7141311 F=E4r=F6gatan 6 | Mobile +46 73 0949021 SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com ---------------------------------------------------------------------- --_000_05F760EF51FA6A4F804F9759C239313A45E750C5A0ESESSCMS0361e_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As part of the comments during IETF 83 on the following drafts

* Media Stream Selection (htt= ps://datatracker.ietf.org/doc/draft-westerlund-dispatch-stream-selection/)

* PAUSE / RESUME (https://datat= racker.ietf.org/doc/draft-westerlund-avtext-rtp-stream-pause/)

* Codec Operation Point (h= ttps://datatracker.ietf.org/doc/draft-westerlund-avtext-codec-operation-poi= nt/)

Very briefly, these are the results (extracts from Section 5.1 of PAUS= E / RESUME draft above, where more detailed descriptions of pre-conditions = and assumptions can be found):

The targeted topology is outlined in the following figure= .

&nbs= p; Provider A's network . Provide= r B's network

&nbs= p; &= nbsp; &nbs= p; .

+-----+ SIP +------+ SIP +-------+= ; SIP +-------+ SIP +-----+

|Proxy|<--->| AS A |<--->| SGW A |<--.--&g= t;| SGW B |<--->|Proxy|

+-----+ +------+&= nbsp; +-------+ . +--= -----+ +-----+

^ &n= bsp; ^ &nb= sp; .&nbs= p; &= nbsp; ^

| &n= bsp; | SIP/H.248 = ; . = |

| &n= bsp; v &nb= sp; .&nbs= p; &= nbsp; |

SIP | +-----+= RTCP +-------+ RTCP +-------+ SIP = |

| &n= bsp; | MCU |<---->| BGW A |<--.-->| BGW B | &n= bsp; |

| &n= bsp; +-----+ +-------+ &= nbsp; . +-------+ &n= bsp; |

v &n= bsp; ^ &nb= sp; .&nbs= p; ^ = ; v

+------+ / RTCP &nbs= p; &= nbsp; . \ RTCP&= nbsp; +------+

| UA A |<---+ &= nbsp; &nbs= p; . = ; +------>| UA B |

+------+ = ; &n= bsp; . &nb= sp; = +------+

In the figure above, UA is a SIP User Agent, Proxy is a S= IP Proxy, AS

is an Application Server, MCU is a Multipoint Conference = Unit, SGW a

Signaling GateWay, and BGW a media Border GateWay.

...

As a partial result, the message sizes can be compared, b= ased on the

messages defined in this specification (Section 8) and a = SIP UPDATE

with contents (Section 10) as discussed above. Favo= rable and

unfavorable message sizes are presented as stacked bars i= n the figure

below. Message sizes include IPv4 headers but no lo= wer layer data,

are rounded to the nearest 25 bytes, and the bars are to = scale.

250= 500 = ; 750 1000 1250= 1500 [byte]

+---------+---------+---------+---------&= #43;---------+---------+--> Size

+-+--+

| |50| 125 RTCP

+-+--+---------------+-------------------= -------------------------+

| SIP &nbs= p; | 525 &= nbsp; &nbs= p; &= nbsp; 1650 |

+--------------------+---------------------------= -----------------+

...

Favorable RTCP size comes from using non-compound RTCP packets.

Favorable SIP size comes from using dynamic SIP SigComp.

...

The signaling delay results of the study are summarized i= n the

following two figures. Favorable and unfavorable va= lues are

presented as stacked bars. Since there are many fac= tors that impact

the calculations, including some random processes, there = are

uncertainty in the calculations and delay values are thus= rounded to

nearest 5 ms. The bars are to scale.

&nbs= p; 50 100 = 150 200 &= nbsp; 250 300 [ms]

+---------+---------+---------+---------&= #43;---------+---------+---> t

| Wireless UA to Wireless UA

+---------------------+--------------------------= ------------+

| SIP &nbs= p; | 110 &= nbsp; &nbs= p; &= nbsp; | 305

+-----+---------------+----------------------= -------+--------+

|RTCP | 30 = ; &n= bsp; = ; | 260

+-----+------------------------------------------= ---+

| Wireless UA to MCU

+-------------+--+

| SIP |70= | 85

+----+--------+--+-----------------------= ---+

|RTCP| 25 = &nb= sp; = | 225

+----+--------------------------------------+=

| MCU to Wireless UA

+--------------+---------------------------------= --+

| SIP &nbs= p; | 75 &n= bsp; = ; | 255

+---+----------+-----------------------------= -+----+

| | 20 RTCP &nbs= p; &= nbsp; &nbs= p; | 230

+---+-----------------------------------------= 3;

...

Below are the same cases for fixed access depicted. = Although delays

are generally shorter, scales are kept the same for easy = comparison

with the previous figure.

&nbs= p; 50 100 = 150 200 &= nbsp; 250 300 [ms]

+---------+---------+---------+---------&= #43;---------+---------+---> t

| Fixed UA to Fixed UA

+------------+

| SIP | 65

+----+-------+---------------------------+= ;

|RTCP| 25 = &nb= sp; | 205

+----+-----------------------------------+

| Fixed UA to MCU

+---------+

| SIP | 50

+---+-----+-----------------------+

| | 15 RTCP &nbs= p; &= nbsp; | 200

+---+-----------------------------+

| MCU to Fixed UA

+---------+

| SIP | 50

+---+-----+-----------------------+

| | 15 RTCP &nbs= p; &= nbsp; | 200

+---+-----------------------------+

This rises further questions to be able to make an informed choice:

* Are there other, general, reasons or recommendations that should

be taken into account when choosing signaling technology?

* What should the signaling strategy be when there are multiple nodes<= /div>

that need the signaled information, possibly not being in the d= irect

route between the signaling peers?

My own conclusion is that I would prefer using RTCP for this type of m= edia stream-related signaling, since:

* The media stream-related signaling does not have any major impact on=

the session itself, only what can be considered normal in-sessi= on

variations, and thus there should be no need to notify all sess= ion-

handling functions via SIP

* All media-handling nodes are already in the media path and will

automatically have access to this new signaling, but may of cou= rse

have to implement support for it if they need to act on it

* The difference in signaling bandwidth is definitely in RTCP's favor<= /div>

* The RTCP signaling delay has a clear potential to be lower than SIP<= /div>

and it should already be possible to configure RTCP such that t= his

low delay can be achieved in a large majority of cases

Comments on the above are greatly appreciated!

Cheers,

Bo Burman

----------------------------------------------------------------------=

Multimedia Technologies, Ericsson Research EAB/TVM

----------------------------------------------------------------------=

Ericsson AB = ; | Phone +46 10 7141311

F=E4r=F6gatan 6 &= nbsp; | Mobile +46 73 0949021

SE-164 80 Stockholm, Sweden | mailto: bo.burman@ericsson.com

----------------------------------------------------------------------=

--_000_05F760EF51FA6A4F804F9759C239313A45E750C5A0ESESSCMS0361e_-- From mary.ietf.barnes@gmail.com Mon Jul 30 09:01:52 2012 Return-Path: X-Original-To: rai@ietfa.amsl.com Delivered-To: rai@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BFE611E80A2; Mon, 30 Jul 2012 09:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.534 X-Spam-Level: X-Spam-Status: No, score=-103.534 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZMb63bC+WGJ; Mon, 30 Jul 2012 09:01:51 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD51811E8091; Mon, 30 Jul 2012 09:01:38 -0700 (PDT) Received: by lbbgo11 with SMTP id go11so3756685lbb.31 for ; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PId8U94hGEYbu5smaElfkBUjb1gvpuDGTWoqh9zUkwE=; b=r9iy1q1yXoxn/VCdB6qwt8oVHTTwJuEfMOnfn4NFb96x0Xm8VQuHv90LzQq2CWoBmM 9k4w2x7MY7UoUUJWbzqsQxXvmd86aEizyY4aOBW0pyNDL/ooaemoU4Qs740s29AOjC7+ tINCt5vkaa3b2G34PeCsVSK+yiXSpsuCXyq9C+5DBpvbZZN1YdaYyVHRi9cF6EZiyBk0 pEI1qTMeoLSXrZk7OcLlwTwb4SqXcjZ2N/XqfP3zYawE8Y7zhm3cQ3MxEqsXvoHS/kDj Eky7RYNfG++5LxD1a98Qyt71Ut7vFiBubdxE2MwoOMMHDXCH/JyOJ3ILFtpInokJgOQy z/0Q== MIME-Version: 1.0 Received: by 10.152.135.200 with SMTP id pu8mr11865796lab.8.1343664097632; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) Received: by 10.112.85.196 with HTTP; Mon, 30 Jul 2012 09:01:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 30 Jul 2012 11:01:37 -0500 Message-ID: From: Mary Barnes To: rai@ietf.org, mmusic@ietf.org, avt@ietf.org, rtcweb@ietf.org Content-Type: multipart/alternative; boundary=f46d043745473ca27b04c60e2ddb Subject: Re: [RAI] Reminder: "Telepresence Tutorial" @ IETF-84 (Please RSVP) X-BeenThere: rai@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Real-time Applications and Infrastructure \(RAI\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 16:01:52 -0000 --f46d043745473ca27b04c60e2ddb Content-Type: text/plain; charset=ISO-8859-1 Tutorial is in Georgia A. On Tue, Jul 10, 2012 at 6:37 PM, Mary Barnes wrote: > Hi all, > > Apologies to the many of you that are receiving this multiple times. > Unfortunately, the RAI list is not a superset of participants in WGs > that might be interested in this. Folks that aren't on the RAI list > might want to subscribe here: > https://www.ietf.org/mailman/listinfo/rai > > Please note the important update below with regards to (no) lunch. > > We are planning a lunchtime tutorial on Monday, July 30th. The > primary objective is to provide more background on telepresence as > well as an update of the work in CLUE to the broader RAI and IETF > community. This will hopefully facilitate the process of completing > the CLUE protocol work as it gets broader community review. > > Here's the proposed outline: > 1) Introduction to telepresence > 2) Example telepresence scenarios > 3) Introduction to the CLUE work > 4) High level introduction of framework > 5) One or two use cases as examples of how the CLUE framework is > realized - showing how existing protocols (e.g., SDP, RTP) are > integral to the solution along > with additional signaling for CLUE. > > We have reserved a room for around 50 and attendance will be FCFS, so > please RSVP by Friday, July 13th, 2012 (5pm Pacific) > http://www.doodle.com/mzu3nmdeehkxkiys > > **Important update*: * Please note that we do not have a sponsor for > lunch, thus folks will have to grab something before the tutorial (sorry, I > tried). However, we will have some cookies and veggies/fruit available so > folks will have something to munch. > > Please send any questions/comments to me (or to the CLUE WG mailing list) > rather than reply all. > > Regards, > Mary > CLUE WG co-chair > > --f46d043745473ca27b04c60e2ddb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Tutorial is in Georgia A.=A0

On Tue, Jul = 10, 2012 at 6:37 PM, Mary Barnes <mary.ietf.barnes@gmail.com&= gt; wrote:

Hi all,

Apologies to the many of you that are receiving this multiple times.
Unfortunately, the RAI list is not a superset of participants in WGs
that might be interested in this. =A0Folks that aren't on the RAI list<= br> might want to subscribe here:
htt= ps://www.ietf.org/mailman/listinfo/rai
=
Please note the important update below= with regards to (no) lunch.=A0

We are planning a lunchtime tutorial on Monday, July 30th. =A0The
primary objective is to provide more background on telepresence as
well as an update of the work in CLUE to the broader RAI and IETF
community. =A0This will hopefully facilitate the process of completing
the CLUE protocol work as it gets broader community review.

Here's the proposed outline:
1) Introduction to telepresence
2) Example telepresence scenarios
3) Introduction to the CLUE work
4) High level introduction of framework
5) One or two use cases as examples of how the CLUE framework is
realized - showing how existing protocols (e.g., SDP, RTP) are
integral to the solution along
with additional signaling for CLUE.

We have reserved a room for around 50 and attendance will be FCFS, so =A0pl= ease RSVP by=A0Friday, July 13th, 2012 (5pm Pacific)
http:/= /www.doodle.com/mzu3nmdeehkxkiys

*Important= update*: =A0Please note that we do not have a sponsor for lunch, thus = folks will have to grab something before the tutorial (sorry, I tried). =A0= However, we will have some cookies and veggies/fruit available so folks wil= l have something to munch.=A0

Please send any questions/comments to me (or to the CLUE WG mai= ling=A0list) =A0rather than reply all.

Regards,
Mary
CLUE WG co-chair

--f46d043745473ca27b04c60e2ddb--