Hello Christer, Hadriel,

I don't want to delay the publication.

Don't see any principle issue, too.

In case of a future revision of this RFC, then it might be beneficial to try to add a term definition for B2BUA (because the whole taxonomy is actually based on this term).

2nd I suppose a difference between B2BUA vs PROXY, hence might be worth as well to point out differences.

Personally, I could see following resolution proposal (based on ITU terms):

Background: the subject as such was studied in Y.1251 (http://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-Y.1251-200208-I!!PDF-E&type=items ).

Possible definition of term “B2BUA”:

B2BUA:  provides a service interworking function (according clause 3.2/ITU-T Y.1251) with following limitations,

1.       network planes: only IP control and IP user plane;

2.       protocol stack: same protocol at each side of the service interworking function.

NOTE 1: hence, a B2BUA is not a proxy.

Proxy (derived from ITU-T Y.2902): A system authorized to work on behalf of another system including responding to protocol requests.

NOTE 1: hence, a proxy does not provide any interworking function (neither service interworking nor network interworking).

NOTE 2: a proxy as network element is an intermediary node in the sense of identical protocol stacks at incoming and outgoing interfaces of the proxy.

SIP B2BUA:   provides a B2BUA function with for the SIP, i.e., a service interworking function (according clause 3.2/ITU-T Y.1251) in the IP control plane.

NOTE: the service interworking function may include as well the interworking of the protocol stack for SIP transport (e.g., SIP-over-UDP/IP4 to SIP-over-SCTP/IPv6 interworking).

… and then subsequent, derived term definitions for

media plane B2BUA

back-to-back IP host

etc

Just some thoughts,

Albrecht

-----Original Message-----
From: Christer Holmberg [mailto:christer.holmberg <at> ericsson.com]
Sent: Sonntag, 16. Juni 2013 11:04
To: Schwarz, Albrecht (Albrecht); Hadriel Kaplan; <straw <at> ietf.org>
Subject: VS: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types

(As co-chair)

Hi Albrecht,

I do appreciate the fact that you have taken a look at the draft, and studied its applicability from a SG16 perspective.

In the conclusion part, you ask whether there is a need to provide feedback to STRAW.

Keep in mind that the WGLC for the draft has finished, and that publication has been requested by the chairs.

Now, that does not prevent us from taking the draft back to the WG, and do changes, but in order for that to happen there normally has to be some issues that need to be changed/addressed in order to publish the document as an RFC.

Regards,

Christer

-----Alkuperäinen viesti-----

Lähettäjä: straw-bounces <at> ietf.org [mailto:straw-bounces <at> ietf.org] Puolesta Schwarz, Albrecht (Albrecht)

Lähetetty: 16. kesäkuuta 2013 8:13

Vastaanottaja: Hadriel Kaplan; <straw <at> ietf.org>

Aihe: [straw] draft-ietf-straw-b2bua-taxonomy: decomposed gateway model and media plane b2bua types

Hi Hadriel,

fyi, some high-level comments to the taxonomy draft from perspective of decomposed SBCs (according H.248 model) http://ftp3.itu.int/av-arch/avc-site/2013-2016/1306_Osl/AVD-4391.zip

Regards,

Albrecht

_______________________________________________

straw mailing list

straw <at> ietf.org

https://www.ietf.org/mailman/listinfo/straw

Hi,

Can someone please help me understand the interaction between the H.248 Mode property and Signals/Events? We’re testing MGC-MG interop, and aren’t quite agreeing over a Modify request for a termination with a single stream that

·         sets the Mode to RecvOnly

·         plays an external tone.

The key bits of H.248.1 text up for discussion seem to be:

·         from 7.1.7:

The allowed values for the Mode Property are "SendOnly", "RecvOnly", "SendRecv", "Inactive"

and "LoopBack". "SendOnly", "RecvOnly" and "LoopBack" are with respect to the exterior of the

context, so that, for example, a stream set to mode = "SendOnly" does not pass received media into

the context. When a stream is set to "LoopBack" on a termination, media received (Local

Descriptor) on the termination will be looped back to the sending side (Remote Descriptor) of the

termination and no media is passed between that termination and other terminations in the context.

The looped back media shall be sent according to the Remote Descriptor. The default value for the

Mode Property is "Inactive". Signals and events are not affected by the Mode Property. The

LocalControl Mode Property takes precedence over any mode specified in the Local and Remote

Descriptors.

·         From 6.1.1:

• The Topology Descriptor (who hears/sees whom).

The topology of a context describes the flow of media between the terminations within a

context. In contrast, the Mode Property of a termination ("SendOnly"/"RecvOnly"/…)

describes the flow of the media at the egress/ingress of the media gateway.

So I think we've both interpreted the Mode property differently:

·         One view treats the Mode property as absolute: that is, RecvOnly means absolutely no media is sent out to this termination, SendOnly means any and all received media is absolutely ignored. Setting the mode doesn't affect the Signals and Events that are programmed on a given termination, neither does it affect any subsequent programming - but it can and does affect the result of the programming. So in this case a Mode of RecvOnly combined with an external tone means the tone gets played in the DSP but absolutely no media is sent out to that termination.

Another way to explain our implementation is in this picture:

[MG egress/ingress]<--- flow affected by Mode property --->[termination including DSP for signals/events]<--- flow affected by Topology descriptor --->[context media mixpoint]

·         The other (that expects to see the tone played to the termination) effectively says that the Mode property affects the flow of media between the termination and the context media mixpoint:

[MG egress/ingress]<------>[termination including DSP for signals/events]<--- flow affected by Mode and Topology --->[context media mixpoint]

What’s the right answer here? The first view seems to go against the text from 7.1.7, and the second view seems to go against that from 6.1.1.

Please don’t hesitate to get back to me if any of this is unclear. Many thanks in advance,

Mark

----

Mark Overton

Project Manager, Carrier Systems Division

Metaswitch Networks

mark.overton <at> metaswitch.com

+44 20 8366 1177

www.metaswitch.com

Hi all,

When MG has some terminations in out of service state, which are not registered in MGC, MG is sending “service change” message to MGC for each TID’s as seen;

MEGACO/1 [10.10.10.10] Transaction=31582{Context=-{ServiceChange=P25{Services{Method=Restart,Reason="900 Service Restored",20121217T08144897}}}}

Because of not created termination ID’s MGC returns error message, like the one below;

!/1 [100.100.100.100]:2944 P=31582{C=-{SC=P25{ER=430{"Unknown TrmID"}}}}

It is clear. I wonder that;

What message must be sent from MGC to MG just after creating new termination at MGC?

Must it be “service change” message to put TID in service state, or

“modify” message to connect TID to null context as seen below;

!/1 [100.100.100.100]:2944 T=456731602{C=-{MF=P25{E=2600571907{al/*},SG{}}}}

If the service change message is true, what type of mesage format will be sent?

Best Regards,
M. NECAT ISIK

Hi,

Sorry for using the forum for the following help, however since its urgent and am strapped for time, I thought of posting it.

1.       Need to implement and integrate MGCP digitmap - is there any open source available for it which can be used.

2.       Is there any other references apart from RFC, form where I can get more details.

~Thanx
Abhijit