Subject: Re: [Megaco] Topology Questions

From: Frank Reno <[email-masked]>
Date: Thu, 23 Jun 2005 12:09:08 -0700 (PDT)

Hello,

Any more thoughts on my question 2 below? Version 1 of
the protocol apparently allows per stream topology to
exist, but there doesn't seem to be a way to report it
in a topology audit.

Given

Transaction = 1
{
	Context = 1
	{
		Topology {t1, t2, oneway},
		Add = t1 {Media {Stream = 1{...}}}, 
		Add = t2 {Media {Stream = 1{...}}} 
	}
}
Transaction = 2
{
	Context = 1
	{
		Modify = t1 {Media {Stream = 2{...}}}, 
		Modify = t2 {Media {Stream = 2{...}}} 
	}
}
Transaction = 3
{
	Context = 1
	{
		ContextAudit{Topology}
	}
}

In version 2, the reply to transaction 3 would look
like

Reply = 3
{
	Context = 1
	{
		Topology
		{
			t1, t2, Oneway, Stream=1,
			t1, t2, Bothway, Stream=2
		}
	}
}

How should a version 1 MG reply?

- Same as version 2 (would need the IG to allow stream
IDs in the reply)
- Some error code
- Multiple triples for the same pair of terminations
("t1, t2, Oneway, t1, t2, Bothway")
- One triple per pair, merging the modes somehow ("t1,
t2, Bothway")

Some more questions on the topology audit...

4. How should the MG reply to a topology audit when
there is only one termination in the context? In the
text encoding, it is impossible to encode an empty
topology descriptor. Can we change the grammar to
allow this, or should the MG use some dummy triple
such as "t1, t1, bothway" or "*, *, bothway"?

5. What topology association should be reported for
terminations that are in the same context but do not
share any streams with the same streamID? Should it be
oneway or bothway or should no association be
reported? No association seems best to me, but we
would need to allow the empty topology descriptor (in
case there are no other associations to report).

6. It looks like the Topology Descriptor is being
moved inside the contextAttrDescriptor in the version
3 ABNF. Won't this break compatibility?

Regards,
Frank

--- Frank Reno <[email-masked]> wrote:

Thanks for the reply, Kevin.

2.  Your rule seems to make good sense for version 2.
Does this mean, however, that a version 1 MG should
support per-stream topology even though the MGC cannot
control it directly?

For my example, I'm assuming that you mean that the
topology regarding stream 1 is unchanged by the
addition of stream 2, regardless of protocol version.
This would leave stream 1 oneway and stream 2
bothways. A version 1 MG would have no way to describe
this in a topology audit.

Thanks

--- Kevin Boyle <kboyle at nortel.com> wrote:

> 1. Only those currently in the context. In your
> example, flow is bothway
> between a/2 and b/1.
> 2. Only to existing streams. In your example, flow
> on stream 2 is bothway.
> The answer is the same in all version of the
> protocol.
> 3. The correct response is the one that lists all
> the associations, though I
> can see the utility of the one immediately below
> that which uses wildcards
> to reduce the message size.
> 
> Kevin
> 
> -----Original Message-----
> From: megaco-bounces at ietf.org
> [mailto:megaco-bounces at ietf.org] On Behalf Of
> Frank Reno
> Sent: Thursday, June 02, 2005 5:16 PM
> To: megaco at ietf.org
> Subject: [Megaco] Topology Questions
> 
> Hello List,
> 
> 1. Does a topology association with wildcarded
> termination IDs apply to
> terminations added to the context in the future or
> only to those currently
> in the context?
> 
> 	Transaction = 1
> 	{
> 		Context = 1
> 		{
> 			Topology {a/*, b/*, oneway},
> 			Add = a/1, Add = b/1
> 		}
> 	}
> 	Transaction = 2
> 	{
> 		Context = 1
> 		{
> 			Add = a/2
> 		}
> 	}
> 
> 	What is the media flow between a/2 and b/1?
> 
> 2. Does a topology association between two
> terminations apply to new streams
> created on the terminations?
> 
> 	Transaction = 1
> 	{
> 		Context = 1
> 		{
> 			Topology {t1, t2, oneway},
> 			Add = t1 {Media {Stream = 1{...}}}, 
> 			Add = t2 {Media {Stream = 1{...}}} 
> 		}
> 	}
> 	Transaction = 2
> 	{
> 		Context = 1
> 		{
> 			Modify = t1 {Media {Stream = 2{...}}}, 
> 			Modify = t2 {Media {Stream = 2{...}}} 
> 		}
> 	}
> 
> 	What is the media flow between t1 and t2 for stream
> 2?
> 	Is the answer different between protocol version 1
> and 2?
> 
> 
> 3. What does the reply to an audit of the topology
> descriptor look like? I
> assume it's valid to include an association for
> every pair of terminations
> (or
> streams) but this may lead to large message. Is it
> valid to only describe
> the links that are missing?
> 
> 
> 	Transaction = 1
> 	{
> 		Context = 1
> 		{
> 			Topology {t1, t2, oneway},
> 			Add = t1, Add = t2, Add = t3, Add = t4
> 		}
> 	}
> 	Transaction = 2
> 	{
> 		Context = 1
> 		{
> 			ContextAudit {Topology}
> 		}
> 	}
> 
> 
> 	Is this valid?
> 
> 	Reply = 2
> 	{
> 		Context = 1
> 		{
> 			Topology {
> 			t1, t2, oneway
> 			}
> 		}
> 	}
> 
> 	Or must all links be specified like one of these:
> 
> 
> 	Reply = 2
> 	{
> 		Context = 1
> 		{
> 			Topology {
> 			t1, t2, oneway,
> 			t1, t3, bothway,
> 			t1, t4, bothway,
> 			t2, t3, bothway,
> 			t2, t4, bothway,
> 			t3, t4, bothway
> 			}
> 		}
> 	}
> 
> 	Reply = 2
> 	{
> 		Context = 1
> 		{
> 			Topology {
> 			t1, t2, oneway,
> 			t3, *, bothway,
> 			t4, *, bothway
> 			}
> 		}
> 	}
> 
> 
> cheers,
> frank
> 

____________________________________________________ 
Yahoo! Sports 
Rekindle the Rivalries. Sign up for Fantasy Football 
http://football.fantasysports.yahoo.com

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Fri, 24 Jun 2005 12:05:35 +1000

Hello Frank,

Version 1 does not allow topology per stream at least by setting the topology 
descriptor or by audit. This was only added in Version 2. The problem you 
highlight was one of the reasons for adding streams in v2.

For version 2 the return to the audit should be bothway because the terminations 
are bothway connected. (Remember v1 has no concept of streams for topology).

Please see my responses below.

Regards, Christian

> such as "t1, t1, bothway" or "*, *, bothway"?

[CHG] If a context contains a termination I'm not sure an empty descriptor is 
best. A triple to indicate may be better e.g. t1,*,isolate. Its the topology you 
would use to isolate a single termination which effectively is what a 
termination in a context by itself is. I don't think *,*,bothway is appropriate 
as it doesn't even return the name of the one termination.

> case there are no other associations to report).

[CHG] If the termination has no association with any other report 
[T1,*,isolate]. This would be the triple that sets the associated.

> 3 ABNF. Won't this break compatibility?

[CHG] The coding on the line shouldn't change. So you are correct this shouldn't 
be moved. Kevin can you fix this in your editing updates?

---

From: Frank Reno <[email-masked]>
Date: Fri, 24 Jun 2005 08:21:26 -0700 (PDT)

Thanks for the reply. Did you mean "For version 1 the
return to the audit should be bothway"? So can we say
that if flow exists in a given direction for any
stream, then flow is reported for that direction at
the termination level? For example

t1, t2, oneway, stream=1
t2, t1, oneway, stream=2

is reported in version 1 as

t1, t2, bothway

Here's another one...

7. Section 7.1.18 states that "It is possible to have
an action containing only a Topology descriptor". In
the text encoding, what should the response be to such
an action? The ABNF requires something in the
actionReply - at least one context property, command
reply or error descriptor.

--- Christian Groves <[email-masked]>

> >>terminations added to the context in the future or
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: Christian Groves <[email-masked]>
Date: Mon, 27 Jun 2005 10:50:21 +1000

Hello Frank,

Please see my replies below.

Regards, Christian

Frank Reno wrote:

> return to the audit should be bothway"? 

[CHG] Yes I meant version 1...seems to be a disconnect between the brain and the 
fingers lately :).

So can we say
> is reported in version 1 as

[CHG] Yes.
If the example was t1,t2,oneway, stream=1
		   t1,t2,oneway, stream=2

it will be reported as t1,t2,oneway.

> reply or error descriptor.

[CHG] Another ABNF quirk to fix in v3. I would say that for v1 and v2 you should 
echo back what was sent. If CHOOSE $ was indicated you should send back the 
chosen terminationId.
In terms of a fix to be equivalent with the ASN.1 you probably want to make the 
command reply optional ie.

actionReply			= CtxToken EQUAL ContextID LBRKT
					[ (errorDescriptor /
					commandReply /(commandReply COMMA
					errorDescriptor)) ] RBRKT

>>>Any more thoughts on my question 2 below? Version
>>
>>1 of
>>
>>>the protocol apparently allows per stream topology
>>
>>to
>>
>>>exist, but there doesn't seem to be a way to
>>
>>report it
>>
>>>in a topology audit.
>>>
>>>Given
>>>
>>>Transaction = 1
>>>{
>>>	Context = 1
>>>	{
>>>In version 2, the reply to transaction 3 would
>>
>>look
>>
>>>like
>>>
>>>Reply = 3
>>>{
>>>	Context = 1
>>>	{
>>>		Topology
>>>		{
>>>- Same as version 2 (would need the IG to allow
>>
>>stream
>>
>>>IDs in the reply)
>>>- Some error code
>>>- Multiple triples for the same pair of
>>
>>terminations
>>
>>>- One triple per pair, merging the modes somehow
>>
>>("t1,
>>
>>>t2, Bothway")
>>>
>>>
>>>4. How should the MG reply to a topology audit
>>
>>when
>>
>>>there is only one termination in the context? In
>>
>>the
>>
>>>5. What topology association should be reported
>>
>>for
>>
>>>terminations that are in the same context but do
>>
>>not
>>
>>>share any streams with the same streamID? Should
>>
>>it be
>>
>>>would need to allow the empty topology descriptor
>>
>>(in
>>
>>>moved inside the contextAttrDescriptor in the
>>
>>version
>>
>>>2.  Your rule seems to make good sense for version
>>
>>2.
>>
>>>Does this mean, however, that a version 1 MG
>>
>>should
>>
>>>support per-stream topology even though the MGC
>>
>>cannot
>>
>>>control it directly?
>>>
>>>For my example, I'm assuming that you mean that
>>
>>the
>>
>>>addition of stream 2, regardless of protocol
>>
>>version.
>>
>>>bothways. A version 1 MG would have no way to
>>
>>describe
>>