Subject: [Megaco] draft-ietf-megaco-callflows-00.txt

From: Raphael Tryster <[email-masked]>
Date: Thu, 18 Apr 2002 21:37:53 +0200

I have some questions about the examples in this document relating to call
transfer:

1.	When UserB presses flash and is dialing UserC, what happens with
UserA?  It appears to me that in steps 19 through 30, nothing happens that
affects UserA, so UserA and UserB would continue to hear each other.  Is
this a real world scenario?  If not, what would happen in the real world?

2.	In the description before step 24, I think that "The physical
termination TermA is added to context 1" should be "The physical termination
TermC is added to context 3".

3.	Step 31 seems to be missing the ephemeral termination EphB, referred
to in the description preceding it.

4.	After step 31, the remote SDP of UserB and UserC point to each
other, but the remote SDP of UserA still points to UserB.  What is the
physical effect of this?

	And about call waiting:

5.	I believe the description before step 26 should refer to TermC
instead of TermB, and MG3 instead of MG2.

6.	In this example, each of the physical terminations has a single
ephemeral termination in the same context, and the MGC sends updated remote
SDP information each time UserB presses flash.  What are the considerations
for doing it this way, rather than creating in UserB's context a separate
ephemeral termination for each of its conversation partners and switching
the mode, such that at any time one is sendrecv and the others are inactive?

7.	What happens to UserA while UserB is in conversation with UserC?
UserA's remote SDP information still points to UserB.

	And some general questions:

8.	Does it ever make sense, and is it possible, to send a signal
"backwards" to a user by directing it at an ephemeral termination to which
it is connected?  For example, when UserA and UserB have EphA and EphB
pointing to each other, is it possible for an MGC to send a signal to EphA
to be sent to UserB?

9.	Under what circumstances, is any, could there be more than one
physical termination in a context?

Raphael Tryster

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 18 Apr 2002 15:43:57 -0400

draft-ietf-megaco-callflows-00.txtHI Tryster,
Thanks for your review comments. My answers embedded [Madhubabu]
  -----Original Message-----
  From: Raphael Tryster [mailto:[email-masked]]
  Sent: Thursday, April 18, 2002 3:38 PM
  To: [email-masked]; [email-masked];
[email-masked]
  Cc: [email-masked]'
  Subject: draft-ietf-megaco-callflows-00.txt

    1.. When UserB presses flash and is dialing UserC, what happens with
UserA?  It appears to me that in steps 19 through 30, nothing happens that
affects UserA, so UserA and UserB would continue to hear each other.  Is
this a real world scenario?  If not, what would happen in the real world?
    [Madhu Babu ]  One of the steps shown in the figure is missing in the
explanation. The message that makes the UserA mode to recvonly. Probably
making the mode to "inactive" will be an better idea. This will be updated.
    2.. In the description before step 24, I think that "The physical
termination TermA is added to context 1" should be "The physical termination
TermC is added to context 3".
    [Madhu Babu] That's right, needs an updation.
    3.. Step 31 seems to be missing the ephemeral termination EphB, referred
to in the description preceding it.
    [Madhu Babu Brahmanapally] The message should refer to EphB rather than
TermB.

    4.. After step 31, the remote SDP of UserB and UserC point to each
other, but the remote SDP of UserA still points to UserB.  What is the
physical effect of this?
    [Madhu Babu Brahmanapally] Making the EphA of User A inactive should
take care this scenario. Even if remote SDP is valid, if the termination
mode to "inactive" there would be no generation of packets.

    And about call waiting:

    5.. I believe the description before step 26 should refer to TermC
instead of TermB, and MG3 instead of MG2.
    [Madhu Babu Brahmanapally]  Yes, the description should refer to TermC.
    6.. In this example, each of the physical terminations has a single
ephemeral termination in the same context, and the MGC sends updated remote
SDP information each time UserB presses flash.  What are the considerations
for doing it this way, rather than creating in UserB's context a separate
ephemeral termination for each of its conversation partners and switching
the mode, such that at any time one is sendrecv and the others are inactive?
    [Madhu Babu Brahmanapally] Yes, that's another possibility. But we opted
for having a only two terminations in the context as this makes the
explanation simple.
    7.. What happens to UserA while UserB is in conversation with UserC?
UserA's remote SDP information still points to UserB.
    [Madhu Babu Brahmanapally] Even in this example, that specific message
making the EphA inactive is missing. (Even though shown in the figure).

    8.. Does it ever make sense, and is it possible, to send a signal
"backwards" to a user by directing it at an ephemeral termination to which
it is connected?  For example, when UserA and UserB have EphA and EphB
pointing to each other, is it possible for an MGC to send a signal to EphA
to be sent to UserB?
    [Madhu Babu Brahmanapally] If there is any activity on a given ephemeral
termination, the other also should have the same effect.  Considering the
example of call transfer, as pointed by you, since the ephemeral A is in
"sendrecv" mode, it should Infact hear the digits dialed by the UserB. As
TermB and EphB are in context and EphB is pointing towards EphA.

    9.. Under what circumstances, is any, could there be more than one
physical termination in a context?
    [Madhu Babu Brahmanapally]  Yes there is a possibility. If call is made
between users connected to the same Media Gateway, there can be a context
only with the physical terminations.   There is no need of other SDP
information at all. Its up to the MGC how it creates these context and add
the terminations into it.

  Raphael Tryster

  Regards
  Madhubabu

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Thu, 18 Apr 2002 15:43:57 -0400

-----Original Message-----
  From: Raphael Tryster [mailto:[email-masked]]
  Sent: Thursday, April 18, 2002 3:38 PM
  To: [email-masked]; [email-masked];

    And about call waiting:

  Raphael Tryster

  Regards
  Madhubabu