Subject: Re: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt

From: Natalia Syracuse <[email-masked]>
Date: Thu, 6 Jul 2000 13:04:06 -0400 (Eastern Daylight Time)

According to our database your draft-rajeshkumar-mmusic-sdp-atm has a
ver02 (not04). I corrected it, please do a note.

Natalia Syracuse

On Fri, 30 Jun 2000, Rajesh Kumar wrote:

>  Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt for placement at the IETF
> site. It obsoletes
>  draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should be   removed. Please
> have it placed
> in the IETF site, after checking if it generally legible and well-formatted
> (Text files sometimes 
> behave idiosyncratically). If formatting is needed, let me know as soon as
> possible.
> 
> Note to Jeorg: We exchanged emails earlier about allocating a 30 minute slot at
> the Pittsburgh IETF
> MMUSIC session. Please let me know the date of the review, and the procedures
> for moving it 
> into standards track expeditiously. That will still give us 6 months of
> industry review on the          
> mailing list [email-masked]' before it moves into rfc status.

---

From: "Mark Watson" <[email-masked]>
Date: Thu, 20 Jul 2000 09:54:01 +0100

Rajesh,

Section 1:

"Applications in which existing path resources are assigned to service
connections. These resources could be AAL1 PVCs (or SPVCs), AAL5 PVCs (or
SPVCs), AAL2 single-CID PVCs (or SPVCs), or channels (CIDs) within AAL2 PVCs
(or SPVCs) that multiplex multiple CIDs."

You have missed the case in which a channel within an existing AAL2
multiple-CID *SVC* is used.

5.7.2 states:

"In the forward SVC establishment model, the call-originating gateway
initiates SVC establishment and transmits an eecid to the call-terminating
gateway via SDP."

In BICC forward call model it is the call-terminating gateway which sends
the BNC-ID/EECID to the call-originating gateway (via SDP), which then
returns the EECID value within the SVC extablishment signalling.

Equally:

"The value of the eecid attribute values needs to be unique within the
gateway initiating the SVC set-up but not across multiple gateways. "

The value should be unique within the gateway *terminating* the SVC. Since
the value is generated and processed only by the Gateway terminating the
SVC, and never by any other node, the sentance following the one quoted
above is not needed, and neither is the qualification of the EECID with an
ATM address.

The mechanism is symetrical between forward and backward call models. In
both cases the gateway *receiving* the SVC request is the one which
generated the EECID value. The value is first passed in the Call Control
signalling from one end to the other, and then back in the SVC
establishment. In this was the SVC establishment can be correlated with the
Call at the end receiveing the SVC request.

Well, the above goes if you want EECID to be synonymous with BNC-ID as
stated in the draft.

Forgive me if I haven't read the draft carefully enough, but I didn't spot
any procedure definitions. For example, I can see how to code an ATM end
system address in the c= or m= line, and an eecid in an a= line, but what is
the procedure I should use, say, for backward SVC establishment. I need to:

(1) request the eecid and media gateway address of the originating MG from
that MG
(2) receive a response from the O-MG containing that information
(3) send the eecid and O-MG address to the terminating MG, with an
(implicit/explicit) indication that SVC setup should be initiated
(4) receive a response from O-MG to O-MGC indicating that an SVC has been
extablished
(5) receive a response from T-MG to T-MGC that SVC confirmation has been
received.

If these procedures, and the formats & codes which go with them, are clear
in the IETF, there is some chance of preventing ITU-T Study Group 11
inventing its own extenstion to Megaco for this purpose.

Regards,

Mark Watson
Nortel Networks

-----Original Message-----
From: Rajesh Kumar [mailto:[email-masked]]
Sent: 30 June 2000 22:44
To: Rosen, Brian; 'Natalia Syracuse'; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt

 Attached is draft-rajeshkumar-mmusic-sdp-atm-04.txt for placement at the
IETF site. It obsoletes
 draft-rajeshkumar-mmusic-sdp-atm-01.txt, which should be   removed. Please
have it placed
in the IETF site, after checking if it generally legible and well-formatted
(Text files sometimes 
behave idiosyncratically). If formatting is needed, let me know as soon as
possible.

Note to Jeorg: We exchanged emails earlier about allocating a 30 minute slot
at the Pittsburgh IETF
MMUSIC session. Please let me know the date of the review, and the
procedures for moving it 
into standards track expeditiously. That will still give us 6 months of
industry review on the          
mailing list [email-masked]' before it moves into rfc status.

---

From: "Sophia Scoggins" <[email-masked]>
Date: Thu, 20 Jul 2000 11:55:56 -0400

Mark,

Regardless forward or backward setup, the principle is whichever MG
(generating MG) chooses an EECID, the other MG (recipient MG) will start the
UNI SETUP. So that the generating MG will not blindly accept the setup
request (although if race condition happens, the MG can choose to blindly
accept the request). In the case that caching is used, the recipient MG will
choose the existing SVC out of its caching pool.
 
The EECID is unqiue within the genering MG, not the recipient MG. This is
because the generating MG has no knowledge about how to make it unique at
the recipient MG. The combination of EECID and MG address can uniquely
identify a connection across the network. 
 
We have an internal paper to demonstrate many different call flows. I will
clean it up and publish the paper to the IETF Megaco and ITU-T SG11 for
reference very soon.

Regards, Sophia 

-----Original Message-----
From: Watson, Mark [MAIFP:EP11-M:EXCH] 
Sent: Thursday, July 20, 2000 4:54 AM
To: 'Rajesh Kumar'
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Submission: draft-rajeshkumar-mmusic-sdp-atm-04.txt

Rajesh, 

Section 1: 

5.7.2 states: 

Equally: 

Regards, 

Mark Watson 
Nortel Networks

---

From: Rajesh Kumar <[email-masked]>
Date: Thu, 20 Jul 2000 11:30:39 -0700

Mark,

A minor point: The draft you are looking at is  a relatively older one. A newer
one is at the IETF site. And there is an even newer one that I circulated on
this mailing list yesterday in which I incorporated some later inputs. It was
too late to submit the latest one to the IETF (past the cutoff date).

> multiple-CID *SVC* is used. 

Yes, I will add it.

> In BICC forward call model it is the call-terminating gateway which sends the
> BNC-ID/EECID to the call-originating gateway (via SDP), which then returns
> the EECID value within the SVC extablishment signalling.
>
> Equally: 
>
> the value is generated and processed only by the Gateway terminating the SVC,
> and never by any other node, the sentance following the one quoted above is
> not needed, and neither is the qualification of the EECID with an ATM
> address.
>
> The mechanism is symetrical between forward and backward call models. In both
> cases the gateway *receiving* the SVC request is the one which generated the
> EECID value. The value is first passed in the Call Control signalling from
> one end to the other, and then back in the SVC establishment. In this was the
> SVC establishment can be correlated with the Call at the end receiveing the
> SVC request.
>
> Well, the above goes if you want EECID to be synonymous with BNC-ID as stated
> in the draft. 

EECID is meant to be synonymous with BNC-ID. I admit that the forward call
model is muddy as described in the ID. I will clean it up and align it with
Q.1901 (BICC). I understand the BICC model - there should be no problem doing
that.

> (5) receive a response from T-MG to T-MGC that SVC confirmation has been

There is a brief mention of the procedures. I can add procedure details to a
later draft. I intend to add examples of how these parameters are to be used.
This is stated at the end of the document.

It is too late to add the procedures to the Internet Draft that will be
reviewed in Pittsburgh. I will publish an ID soon after that. I stated in the
last part of the document:

    "In the authors' opinion, the following tasks need to be done to
    complete the definition of the basic conventions needed to describe
    ATM connections in SDP.
     
     -  Additional, detailed examples of  the use of these SDP conventions."

     -  Additional, detailed examples of  the use of these SDP conventions.

>
> If these procedures, and the formats & codes which go with them, are clear in
> the IETF, there is some chance of preventing ITU-T Study Group 11 inventing
> its own extenstion to Megaco for this purpose.

There is no need for that. A lot of work has been put into this draft, and
there is no need to start over. Please work with me in ensuring that this
document is complete. It is near complete, I believe. I have been consistently
open to inputs, and I have responded to them promptly. The inputs I have
received have been mostly in the last month - there was no attention paid to
the draft before that. If it is the intention of the ITU-T SG 11 to do this
thing again from scratch, then please let me know and I will stop my work in
this area.

> From: Rajesh Kumar [<mailto:[email-masked]>mailto:[email-masked]] 
> Sent: 30 June 2000 22:44 
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
>

Thank you very much.

Rajesh Kumar

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
[email-masked]                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^

---

From: Rajesh Kumar <[email-masked]>
Date: Thu, 20 Jul 2000 17:22:58 -0700

Mark,

I hope you didn't miss my responses to your comments below.

Yes, I will add it.

     

Thank you very much.

Rajesh Kumar

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
[email-masked]                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^

Thank you very much.

Rajesh Kumar

^^^^^^^^^^^^^^^^^^^^^
Rajesh Kumar, Ph.D.
Technical Leader        
Carrier Packet Voice
Cisco Systems
San Jose, California
^^^^^^^^^^^^^^^^^^^^^
[email-masked]                 
408 527 0811                
^^^^^^^^^^^^^^^^^^^^^