Subject: RE: [Megaco] Topology Questions

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 2 Jun 2005 18:48:09 -0400

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: [email-masked] [mailto:[email-masked]] On Behalf Of
Frank Reno
Sent: Thursday, June 02, 2005 5:16 PM
To: [email-masked]
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

__________________________________
Discover Yahoo! 
Use Yahoo! to plan a weekend, have fun online and more. Check it out! 
http://discover.yahoo.com/

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

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

---

From: Frank Reno <[email-masked]>
Date: Fri, 3 Jun 2005 08:17:42 -0700 (PDT)

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 <[email-masked]> wrote:

> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of
> Frank Reno

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