Subject: RE: Adding Streams

From: Danny Levin <[email-masked]>
Date: Wed, 7 Mar 2001 12:35:05 -0500

what does it mean in a case that the streams Id do not match ?

-----Original Message-----
From: Preeti Sharma [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 11:57 AM
To: [email-masked]
Cc: Rosen, Brian; 'Christian Groves'; [email-masked]'
Subject: Re: Adding Streams

Section 7.1.18 says : The default topology of a Context is that each
termination's
transmission
is received by all other terminations. Is this not in line with what Brian
had to
say.
Preeti.

[email-masked] wrote:

> If the example is that T1 is the source of audio (StreamID = 1) and video
> (StreamID = 2)
> and T2 should be receiving both audio and video but T3 should only be
receiving
> audio
> then T2 will have StreamID = 1 connected to T1's stream and same for
StreamID =
> 2.
> T3 will not be connected to StreamID = 2.
>
> By your logic I can't have T3 not connected to StreamId = 2.
> Sachin
>
> "Rosen, Brian" <[email-masked]> on 03/07/2001 06:42:24 PM
>
> To:   "'Christian Groves'" <[email-masked]>
> cc:   "[email-masked]'" <[email-masked]> (bcc: Sachin Mittal/HSS)
>
> Subject:  RE: Adding Streams
>
> We have a major disconnect on what a stream is, and what multiple streams
> in a context mean.
>
> My view of streams is that a termination normally is connected to all
> streams in a context.  The canonical example is a video conference, which
> would have an audio stream, a video stream and a T.120 stream.  All
> terminations
> in the context are in all streams.
>
> In your example, if T1 & T2 are connected to streams 1 & 2, then when you
> add
> T3, it is connected to streams 1 & 2 and if you then add stream 3, then
> T1 and T2 are connected to stream 3.
>
> If you don't want streams 1 & 2 to be connected to T3, why are you putting
> T3 in the context with T1 and T2?  By your argument, if I have T1 and T2
> connected on stream 1 (forget stream 2 and 3), and Add T3 to the context
> without any media descriptor, it is not connected to anything!
>
> The example you used makes no sense -- if T1 is connected to stream 1 and
> T2 is connected to stream 2, then there is no connection at all, you have
> a bunch of one termination contexts.  If that is what you want, then use
> separate contexts.
>
> Stream IDs exist so you can modify the properties of each stream
> independently.
> They don't imply which terminations are connected to which streams
>
> All terminations are always on all streams in the termination.
>
> Brian
>
> > -----Original Message-----
> > From: Christian Groves [mailto:[email-masked]]
> > Sent: Tuesday, March 06, 2001 8:49 PM
> > To: Rosen, Brian
> > Cc: [email-masked]'
> > Subject: Re: Adding Streams
> >
> >
> > The answer is ABSOLUTELY NO to both questions !!!!!!
> >
> > Stream IDs relate the different streams on terminations.
> >
> > Extend this a little:
> > T1 and T2 have streams 1 & 2. Add T3 with stream 3. Should stream 3 be
> > connected to 1 or 2? The MG can't possibly know. If you send
> > down 1 or 2
> > it is completely unambiguous. The very reason we had stream
> > IDs was for
> > this relation.
> >
> > Christian
> >
> >
> >
> > "Rosen, Brian" wrote:
> > >
> > > Suppose you create a context and add two terminations to it with
> > > StreamId=1.  Then you add a third termination and specify
> > > a media descriptor with StreamId=2.
> > >
> > > Is the third termination connected to the other two on StreamId=1?
> > >
> > > Are the first two terminations connected to the third on StreamId=2?
> > >
> > > I think the answer is yes to both questions.
> > >
> > > Brian
> >

---

From: Preeti Sharma <[email-masked]>
Date: Wed, 07 Mar 2001 13:43:23 -0500

The answer to this should lie in the fact that the domain of StreamIDs is
 local between the MGC and the MG. In that light I wonder whether StreamIDs
 could be session specific too. I think so as StreamID can be deleted.
 This is unlike the Topology of Terminations which are bound to context itself.
  There is no way to delete topoloy .. it exists....even if not specified.

  Also to add to the above, multiple logical MGs (within a single physical MG)
can be associated with different MGCs (section 11)

I believe in such cases MGCs can use StreamIDs to get desirable functionality
for the terminations.

Preeti.

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Wed, 7 Mar 2001 14:29:58 -0500

Hi All,
When the MGC specifies an IP address to MG in remote SDP information, what
will happen if the MG cannot reach the IPAddress specified in the Remote SDP
information?? (Say it cannot ping the other MG) Does it continue sending the
UDP packets? Or does it need to make something to add entries in all the
routing tables in between each of the MGs?
Best Regards
Madhubabu

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 07 Mar 2001 21:37:37 +0200

Hi,

I would say it's an implementation issue what exactly the MG does.
However, if it doesn't manage to contact the other MG, ie establishing
the media connection, I would assume it notifies the MGC about it, and
then it's again an implementation issue what the MGC does. In a normal
case I guess it will delete the connection, and/or maybe try another MG
if possible...

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 8 Mar 2001 11:02:52 -0500

hi Christer,list.
The IP address of the Remote MG is specified by the MGC itself. Hence this
is no more an implementation issue. If the mode is sendrecv, then if the MG
doesn't receive any packets it can report the quality alert event indicating
that the voice quality is falling below the specified threshold. But what is
the case when the mode is just send only??
Best Regards.
Madhubabu

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Wednesday, March 07, 2001 2:38 PM
To: Madhu Babu Brahmanapally
Cc: [email-masked]
Subject: Re: If MG cannot reach other MG

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 08 Mar 2001 18:05:29 +0200

Hi,

Yes, the Remote MG is specified by the MGC, but if the MG can't use that
address it should inform the MGC about it.

Even if you have mode to send only, you probably will receive ICMP
messages if the RTP packages can't reach the remote MG.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 8 Mar 2001 11:29:57 -0500

I agree, The protocol doesn't talk about generation of ICMP messages.
Protocol should speak how to address issues like these, than making it open
for vendor specific implementation.
Best Regards
Madhubabu

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, March 08, 2001 11:05 AM
To: Madhu Babu Brahmanapally
Cc: [email-masked]
Subject: Re: If MG cannot reach other MG

Hi,

Regards,

Christer Holmberg
Ericsson Finland

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 08 Mar 2001 18:35:06 +0200

Hi,

I am not sure if that is a protocol issue. There are package events to
notify about a network error, so if you receive ICMP messages you simply
trigger a proper event. And, if you want to inform the MGC that it was
an ICMP error, I guess you can define an ICMP event, or something.

Regards,

Christer Holmberg
Ericsson Finland