Subject: [Fwd: ServiceChange corrections in Implementers Guide]

From: Chuong Nguyen <[email-masked]>
Date: Tue, 5 Dec 2000 11:34:42 -0600

Ops.  One more point in Section 11. last paragraph

"The MG shall issue error 505 - Command Received before Restart
Response."
The "MG" should be "MGC".

This also brings up an interesting point.

For sure error 505 applies to all commands before Restart but there are
exception for ServiceChange.

For ServiceChange w/method Forced/Graceful, MGC should response w/error
505.
For ServiceChange w/method HandOff or Failover, MGC should either accept
the
registration or provide alternative MGC to try.

Are the above assumption correct?

Thanks
Chuong

Chuong Nguyen wrote:

> Hi Christian
>
> I don't know if this was pointed out already.
> I am looking at H248_Implementors_guide_approved.zip.
>
> The change for Section 6.3  Cold Start has the following:
> "If the MGC accepts the MG, it will send a Transaction Reply, with the
> ServiceChangeMgcId
> set to itself."
>
> The change for Section 11.2 Cold Start has the following:
> "If the MGC accepts the MG's resignation, it sends a Transaction Reply
> not including a
> ServiceChangeMgcId parameter."
>
> This 2 statements contradict each other.
> I think originally it was always "not" including a ServiceChangeMgcId
> parameter.
>
> Also additional words might be added to clearly stated that
> "If the MG receives a Transaction Reply that includes a
> ServiceChangeMgcId parameter, it sends
> a ServiceChange w/a method of Restart to the MGC specified in the
> ServiceChangeMgcId."
>
> Otherwise someone might get confused and use ServiceChange w/a method
> of handoff.
>
> Chuong
>
> --
>   Alcatel USA, Inc             Internet: [email-masked]
>   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
>   **** The opinions expressed are not those of Alcatel USA, Inc ****
>
>

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <[email-masked]>
Date: Thu, 7 Dec 2000 17:49:56 -0500

Comments inline below [KJBII]

Kevin

Chuong Nguyen wrote:

[KJBII] Actually, the text is correct.  This error indicates that
the MG received a command from the MGC before it received the MGC's response
to the ServiceChange Restart.

For sure error 505 applies to all commands before Restart but there
are exception for ServiceChange.

[KJBII] In these cases, the MG is in an active communication state with
the MGC, and then decides that it needs to go out of service.  The
MGC may be in the process of sending a command while the MG is sending
the ServiceChange, and the commands "cross in the mail", so to speak.
In this case, the MG shouldn't reject the commands -- in fact, it should
continue to execute the commands if it can, until it recieves the MGC's
response to the Service Change, effectively taking the MG out of service.

Thanks

Chuong

Chuong Nguyen wrote:

Hi Christian

"If the MGC accepts the MG, it will send a Transaction Reply, with
the ServiceChangeMgcId

set to itself."

not
including
a

"If the MG receives a Transaction Reply that includes a ServiceChangeMgcId
parameter, it sends

a ServiceChange w/a method of Restart to the MGC specified in
the ServiceChangeMgcId."

Chuong

---

From: Chuong Nguyen <[email-masked]>
Date: Fri, 8 Dec 2000 08:09:45 -0600

Ok I miss read the thing.

I wanted to ask about Error code for MGC to send to MG if MG sends up
any command
before MG does a ServiceChange with Restart.

Said if MGC receives ServiceChange w/Forced/Graceful before receiving
ServiceChange
w/Restart from MG, what should the MGC do:

1) ignore the ServiceChange w/Forced/Graceful?
2) send a ServiceChange reply w/an Error code of ????

Thanks
Chuong

"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:

> [KJBII] Actually, the text is correct.  This error indicates that the
> MG received a command from the MGC before it received the MGC's
> response to the ServiceChange Restart.

>> For ServiceChange w/method Forced/Graceful, MGC should response
>> w/error 505.
>> For ServiceChange w/method HandOff or Failover, MGC should either
>> accept the
> [KJBII] In these cases, the MG is in an active communication state
> with the MGC, and then decides that it needs to go out of service.
> The MGC may be in the process of sending a command while the MG is
> sending the ServiceChange, and the commands "cross in the mail", so to
> speak.  In this case, the MG shouldn't reject the commands -- in fact,
> it should continue to execute the commands if it can, until it
> recieves the MGC's response to the Service Change, effectively taking
> the MG out of service.
>
>>
>> Thanks
>> Chuong
>>
>> Chuong Nguyen wrote:
>>
>> > Hi Christian
>> >
>> > "If the MGC accepts the MG's resignation, it sends a Transaction
>> > Reply not including a
>> > I think originally it was always "not" including a
>> > ServiceChangeMgcId parameter.
>> >
>> > Otherwise someone might get confused and use ServiceChange w/a
>> > method of handoff.
>> >
>> > Chuong
>> >
>> > --

---

From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <[email-masked]>
Date: Fri, 8 Dec 2000 13:49:58 -0500

I would say that the MGC will process them like any other communication
from the MG: in the order of receipt.  That is, the MGC will finish
processing the Restart, and then process the Forced/Graceful appropriately.

Kevin

Chuong Nguyen wrote:

Thanks

Chuong

Kevin

Chuong Nguyen wrote:

Thanks

Chuong

Chuong Nguyen wrote:

Hi Christian

set to itself."

Chuong

---

From: Chuong Nguyen <[email-masked]>
Date: Fri, 8 Dec 2000 14:28:46 -0600

You are missing the point.
ServiceChange w/Forced or Graceful comes before ServiceChange w/Restart
in different
messages.

I am looking at error handling.
MG did not send ServiceChange w/Restart but started sending
ServiceChange w/Forced/Graceful.

Kevin Boyle wrote:

> I would say that the MGC will process them like any other
> communication from the MG: in the order of receipt.  That is, the MGC
> will finish processing the Restart, and then process the
> Forced/Graceful appropriately.
>
> Kevin
>
> Chuong Nguyen wrote:
>
>> I wanted to ask about Error code for MGC to send to MG if MG sends
>> up any command
>> Said if MGC receives ServiceChange w/Forced/Graceful before
>> receiving ServiceChange
>> > the MG received a command from the MGC before it received the MGC's
>> >>  For sure error 505 applies to all commands before Restart but
>> >>  there are exception for ServiceChange.
>> >>
>> > sending the ServiceChange, and the commands "cross in the mail", so
>> > to speak.  In this case, the MG shouldn't reject the commands -- in
>> > fact, it should continue to execute the commands if it can, until
>> > it recieves the MGC's response to the Service Change, effectively
>> > taking the MG out of service.
>> >
>> >>
>> >>  Thanks
>> >>  Chuong
>> >>
>> >>  Chuong Nguyen wrote:
>> >>
>> >> > Hi Christian
>> >> >
>> >> > "If the MGC accepts the MG, it will send a Transaction Reply,
>> >> > with the ServiceChangeMgcId
>> >> > set to itself."
>> >> >
>> >> > "If the MGC accepts the MG's resignation, it sends a
>> >> > Transaction Reply not including a

---

From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <[email-masked]>
Date: Mon, 11 Dec 2000 11:12:50 -0500

OK... it was my turn to misread this time.  In the case of a MG that
is not actively communicating with MGC, I would say all messages except
a ServiceChange Restart would be ignored.  If you choose to send error
messages to these kinds of things, you open the protocol to denial of service
attacks from unknown parties.  An unregistered party could send an
overwhelming number of messages to a MGC, and the MGC would waste processing
resources trying to respond to every one of them.  Even if the MGC
could keep up, now you've overwhelmed the network with message traffic
that will impact legitimate traffic.  If the MGC throws these messages
away without response, then the traffic is minimized as much as possible
in these scenarios, and the MGC is not wasting processing time trying to
respond and keep up.

Kevin

Chuong Nguyen wrote:

messages.

MG did not send ServiceChange w/Restart but started sending ServiceChange
w/Forced/Graceful.

Kevin Boyle wrote:

I would say that the MGC will process them like any
other communication from the MG: in the order of receipt.  That is,
the MGC will finish processing the Restart, and then process the Forced/Graceful
appropriately.

Kevin

Chuong Nguyen wrote:

Thanks

Chuong

Kevin

Chuong Nguyen wrote:

Thanks

Chuong

Chuong Nguyen wrote:

Hi Christian

set to itself."

Chuong

---

From: Chuong Nguyen <[email-masked]>
Date: Tue, 12 Dec 2000 08:38:56 -0600

Based on your line of reasoning, wouldn't it be the same defensive
stragtegy for MG to ignore
commands from MGC if the MG has not established an association w/the
MGC.

That is MG would not Reply w/any error code to commands from MGC if
MG has not finished registering
w/MGC (or registered w/MGC) to avoid "denial of service attachs from
unknown parties."

Chuong

"Boyle, Kevin [NCRTP:3Z70:EXCH]" wrote:

> is not actively communicating with MGC, I would say all messages
> except a ServiceChange Restart would be ignored.  If you choose to
> send error messages to these kinds of things, you open the protocol to
> denial of service attacks from unknown parties.  An unregistered party
> could send an overwhelming number of messages to a MGC, and the MGC
> would waste processing resources trying to respond to every one of
> them.  Even if the MGC could keep up, now you've overwhelmed the
> network with message traffic that will impact legitimate traffic.  If
> the MGC throws these messages away without response, then the traffic
> is minimized as much as possible in these scenarios, and the MGC is
> not wasting processing time trying to respond and keep up.
>
> Kevin
>
> Chuong Nguyen wrote:
>
>> ServiceChange w/Forced or Graceful comes before ServiceChange
>> w/Restart in different
>> messages.
>>
>> > communication from the MG: in the order of receipt.  That is, the
>> > MGC will finish processing the Restart, and then process the
>> >>  I wanted to ask about Error code for MGC to send to MG if MG
>> >>  sends up any command
>> >> >>  "The MG shall issue error 505 - Command Received before
>> >> >>  Restart Response."
>> >> > [KJBII] Actually, the text is correct.  This error indicates
>> >> > that the MG received a command from the MGC before it received
>> >> > the MGC's response to the ServiceChange Restart.
>> >>
>> >> >
>> >> >
>> >> >>
>> >> >>  For ServiceChange w/method Forced/Graceful, MGC should
>> >> >>  response w/error 505.
>> >> >>  For ServiceChange w/method HandOff or Failover, MGC should
>> >> >>  either accept the
>> >> > [KJBII] In these cases, the MG is in an active communication
>> >> > state with the MGC, and then decides that it needs to go out of
>> >> > service.  The MGC may be in the process of sending a command
>> >> > while the MG is sending the ServiceChange, and the commands
>> >> > "cross in the mail", so to speak.  In this case, the MG
>> >> > shouldn't reject the commands -- in fact, it should continue to
>> >> > execute the commands if it can, until it recieves the MGC's
>> >> >> > "If the MGC accepts the MG, it will send a Transaction
>> >> >> > Reply, with the ServiceChangeMgcId
>> >> >> > set to itself."
>> >> >> >
>> >> >> > a ServiceChange w/a method of Restart to the MGC specified
>> >> >> > in the ServiceChangeMgcId."
>> >> >> >
>> >> >> > Otherwise someone might get confused and use ServiceChange
>> >> >> > w/a method of handoff.
>> >> >> >
>> >> >> > Chuong
>> >> >>
>> >>  --

---

From: "Boyle, Kevin [NCRTP:3Z70:EXCH]" <[email-masked]>
Date: Tue, 12 Dec 2000 13:30:43 -0500

Based on the fact that the MG initiates the ServiceChange, the MGC must
be a known entity.  Therefore, commands issued from that entity should
be responded to with an error.  Take the following example for instance:

The MG sends the ServiceChange to the MGC.

The MGC responds, but due to congestion, the reply is delayed.

In the meantime, the MGC starts sending commands to the MG.

The commands arrive before the ServiceChange replay.

The MGC needs to know that the MG was not able to execute the commands,
and needs to take further action.

However, you do bring up a good point: If a MG recieves commands from
an entity to which MG did NOT send a ServiceChange, those commands should
be silently discarded.

Kevin

Chuong Nguyen wrote:

Based on your line of reasoning, wouldn't it be the
same defensive stragtegy for MG to ignore

Chuong

OK... it was my turn to misread this time.
In the case of a MG that is not actively communicating with MGC, I would
say all messages except a ServiceChange Restart would be ignored.
If you choose to send error messages to these kinds of things, you open
the protocol to denial of service attacks from unknown parties.  An
unregistered party could send an overwhelming number of messages to a MGC,
and the MGC would waste processing resources trying to respond to every
one of them.  Even if the MGC could keep up, now you've overwhelmed
the network with message traffic that will impact legitimate traffic.
If the MGC throws these messages away without response, then the traffic
is minimized as much as possible in these scenarios, and the MGC is not
wasting processing time trying to respond and keep up.

Kevin

Chuong Nguyen wrote:

messages.

Kevin Boyle wrote:

Kevin

Chuong Nguyen wrote:

Thanks

Chuong

Kevin

Chuong Nguyen wrote:

Thanks

Chuong

Chuong Nguyen wrote:

Hi Christian

set to itself."

Chuong

---

From: 廖彥彰 <[email-masked]>
Date: Wed, 13 Dec 2000 11:03:56 +0800

Hi Sir :

We have a question about binary encoding in SDP, can you help us?
In Annex A, SDP binary encoding use :
ProperParm :: = SEQUENCE
{
    name    pKgdName,
    value    SEQUENCE OF OCTET STRING,
    ....
}

if I want to encode the following SDP:
v=0
c=IN IP4 $

1. What I need to put in PropertyParm.name ?
v=0                =====> 0000B001
c=IN IP4 $     =====>  0000B008 or 00006001

2. What I need to put in PropertyParm.value?
Is ASCII of all the string "v=0" and "c=IN IP4 $" or someing else ?

Best regards
Yieng-Chang Liao