Subject: Re: [Megaco] supplied address and ServiceChangeAddress

From: [email-masked]
Date: Sun, 1 May 2005 07:45:03 +0200

Hi Jan,
I may understand your background, and I may agree that finally a H.248
Profile might be the right place. But if we go the Profile way, then it may
consequently appear in other Profile specs (like Trunking MG, etc) as well.
Therefore we should double-check.

Particularily, below assumption:
> do not think that H.248 specification can
> explain these assumptions because it cannot make any statement against
> the transport layer.

This assumption is
1) related to H.248 transport statements
   * H.248.1 Annex C.1
   * H.248.1 Annex C.2
   * H.248.4
   * H.248.5

and secondly
2) ALF procedures in H.248.1 Annex C.1.

I agree that it is not obvious that your procedure is related to above
H.248 parts, but I think a clear differentiation towards ALF/UDP and
ServiceChange would be helpful.

My understanding again is that this mechanism related to
a) separation between logical and real addresses, and
b) how real addresses (= H.248 transport address) shall be modified in
ServiceChange situations.

It's related to the MID handling section in the AMG Profile (right?; I've
appended a quote from my TD17 below).

I do see following proceeding:
1) if your proposal is not any change request ("this is my understanding"),
then this text is helpful and provides again more background for the MID
section.

2) I would appreciate some further text explaining why it is not related to
ALF (H.248.1 Annex C.1), and an overlay or dedicated application of
ServiceChange parameters.

3) another option might be to describe this procedures in more detail in
our new intended spec/WI for ""Network Operation and System Management of
H.248 Systems"

Best regards,
Albrecht

TISPAN WG3
TD17
H.248 Profile Meeting
Stockholm, 25-26 April 2005
TD17
...
The  2nd item in Profile section § 5.10 is actually about the concept about
"separation  between  logical  and  real  addresses".  A common concept for
support  of  redundancy  within  network  nodes  and  on network level. The
definitive mapping table between both address formats is here located in an
external DNS server.

It has to be further noted that the H.248 MID is principally decoupled from
the  H.248  transport  address (because there are many options to transport
H.248 signalling traffic). But this H.248 Profile is linking both together:
There's  an  association  supposed here between the MID ("logical address")
and the H.248 transport address ("real address").

Binding  changes  here  between  logical and real addresses typically occur
when ServiceChange procedures are performed (in case of system failures).

                      "Jan Lindquist                                                                                                   
                      (AL/EAB)"                 To:      [email-masked]                                                      
                      <jan.lindquist@ER         cc:                                                                                    
                      ICSSON.COM>               Subject: Re: [Megaco] supplied address and ServiceChangeAddress                        
                                                                                                                                       
                      29.04.2005 13:07                                                                                                 
                      Please respond to                                                                                                
                      "Jan Lindquist                                                                                                   
                      (AL/EAB)"                                                                                                        

Hi Albrecht,

Very good question.  I am trying to get this clarified in the megaco
mailing list in order to determine if something needs to be documented
and how.  I agree that H.248 does not mention these assumptions and I
need to get this straightened in order to improve interoperability and
performance of profiles being created in ETSI.

If H.248 is not clear on these assumptions we need to add it to the ETSI
H.248 profiles in general.  I do not think that H.248 specification can
explain these assumptions because it cannot make any statement against
the transport layer.  The profile on the other hand does refer to the
transport layer and therefor can explain interaction between the H.248
layer and transport layer.

I would like to propose that two assumptions are documented in the
TISPAN AGW profile (only applies to UDP transport):

1. The MGC will store the source IP address retrieveed from the first
ServiceChange.  All subsequent messages delivered to the MG will use
this IP address.

2. The MG will store the source IP address retrieved from the reply to
the ServiceChange(1).  All
subsequent messages delivered to the MGC will use this IP address.

Note (1) - The MG will use the DNS lookup in order to retrieve the
initial IP address to send the first ServiceChange.  This IP address may
be different than the IP address returned in the reply to ServiceChange.

Regards,
JanL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: den 29 april 2005 12:02
To: Jan Lindquist (AL/EAB)
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] supplied address and ServiceChangeAddress

Hi Jan,

just an additional comment to the sentence:
"A common
technique with UDP transport of H.248 is to copy the source IP address
in the IP header that is in the first ServiceChange from the MG."

I don't know how to handle such a argument. This seems to be an
assumption, or a specific interpretation, or a "best current practice"
because it is not mentioned in any H.248 Rec. Right?

My question is: do you want to make this implicit assumption as an
explicit proposal, e.g., for ETSI H.248 Profiles? ["because the
subsequent argumentation bases on this hypothesis"]

Best rgds/Albrecht

                      "Kevin Boyle"

                      <[email-masked]         To:      "Jan Lindquist
(AL/EAB)" <[email-masked]>, [email-masked]
                      om>                      cc:

                      Sent by:                 Subject: RE: [Megaco]
supplied address and ServiceChangeAddress
                      megaco-bounces@i

                      etf.org

                      28.04.2005 17:00

There is additional text in that section: "Note that the use of
ServiceChangeAddress is not encouraged."  This is advice that ought to
be followed.

That aside, to answer your question, the paragraph is discussing the
SCAddress parameter alone.  It only indicates that if the SCAddress
parameter is present, then the recipient of the SC command must switch
to that new address.

Note that if the MGC wishes to change its address, it should use Handoff
and the SCMGCID to announce that change.

Kevin

  _____

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jan Lindquist (AL/EAB)
Sent: Thursday, April 28, 2005 10:35 AM
To: [email-masked]
Subject: [Megaco] supplied address and ServiceChangeAddress

Hello,

I would like assistance in the interpretation in the text in H.248
specifically in section 7.2.8 relating to ServiceChangeAddress.  Here is
a copy of the text in question:

"The MG may specify the transport ServiceChangeAddress to be used by the
MGC for sending messages in the ServiceChangeAddress parameter in the
input ServiceChangeDescriptor. The MG may specify an address in the
ServiceChangeAddress parameter of the ServiceChange request, and the MGC
may also do so in the ServiceChange reply. In either case, the recipient
must use the supplied address as the destination for all subsequent
transaction requests within the association."

The H.248 transport to be used is UDP/IP.

The question relates to the last sentence in the above paragraph.  A
common technique with UDP transport of H.248 is to copy the source IP
address in the IP header that is in the first ServiceChange from the MG.
So all subsequent message to the MG will use that MG IP address.  There
is no need for a ServiceChangeAddress.

The question is in the reverse direction.  If I want to change the IP
address that the MG should use for any subsequent messages to the MGC.
The MGC sends a ServiceChange reply with a new IP address to itself.
Shouldn't the MG use that IP address for subsequent messages?

There is a subtle implication in the text that this is acceptable but
what does "supplied address" mean.  For ServiceChange coming from the MG
the IP address in the IP header is the supplied address.  If this
accepted technique for indicating supplied address it is possible to
interprete the ServiceChange reply could indicate the supplied address
for the MGC.

Is this interpretation correct?

Regards,
JanL

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

-------------------------------------------------------------------
Mail archive for TISPAN_WG3  can be browsed at the following url :
         http://list.etsi.org/TISPAN_WG3.html
-------------------------------------------------------------------

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

---

From: "Jan Lindquist \(AL/EAB\)" <[email-masked]>
Date: Mon, 2 May 2005 16:50:57 +0200

Hello Albrecht,

I will send in a contribution on this subject and we can decide in the meeting how to include this type of information.  Section D.1 could be an alternative but I do not think it is ideal since there could be a backwards compatability issue if some vendors do not suppor these assumptions.  There has not been an objections to the discussion in the megaco mailing list so maybe it is ok.

Regards,
JanL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: den 1 maj 2005 07:45
To: Jan Lindquist (AL/EAB)
Cc: [email-masked]; [email-masked]
Subject: Re: [Megaco] supplied address and ServiceChangeAddress

Hi Jan,
I may understand your background, and I may agree that finally a H.248 Profile might be the right place. But if we go the Profile way, then it may consequently appear in other Profile specs (like Trunking MG, etc) as well. Therefore we should double-check.

This assumption is

and secondly

I agree that it is not obvious that your procedure is related to above H.248 parts, but I think a clear differentiation towards ALF/UDP and ServiceChange would be helpful.

My understanding again is that this mechanism related to
a) separation between logical and real addresses, and
b) how real addresses (= H.248 transport address) shall be modified in ServiceChange situations.

It's related to the MID handling section in the AMG Profile (right?; I've appended a quote from my TD17 below).

I do see following proceeding:
1) if your proposal is not any change request ("this is my understanding"), then this text is helpful and provides again more background for the MID section.

2) I would appreciate some further text explaining why it is not related to ALF (H.248.1 Annex C.1), and an overlay or dedicated application of ServiceChange parameters.

3) another option might be to describe this procedures in more detail in our new intended spec/WI for ""Network Operation and System Management of H.248 Systems"

Best regards,
Albrecht

TISPAN WG3
TD17
H.248 Profile Meeting
Stockholm, 25-26 April 2005
TD17
...
The  2nd item in Profile section § 5.10 is actually about the concept about "separation  between  logical  and  real  addresses".  A common concept for support  of  redundancy  within  network  nodes  and  on network level. The definitive mapping table between both address formats is here located in an external DNS server.

It has to be further noted that the H.248 MID is principally decoupled from the  H.248  transport  address (because there are many options to transport H.248 signalling traffic). But this H.248 Profile is linking both together: There's  an  association  supposed here between the MID ("logical address") and the H.248 transport address ("real address").

Binding  changes  here  between  logical and real addresses typically occur when ServiceChange procedures are performed (in case of system failures).

                      "Jan Lindquist                                                                                                   
                                                                                                                                       
                      29.04.2005 13:07                                                                                                 
                      Please respond to                                                                                                
                      "Jan Lindquist                                                                                                   
                      (AL/EAB)"                                                                                                        

Hi Albrecht,

Very good question.  I am trying to get this clarified in the megaco mailing list in order to determine if something needs to be documented and how.  I agree that H.248 does not mention these assumptions and I need to get this straightened in order to improve interoperability and performance of profiles being created in ETSI.

If H.248 is not clear on these assumptions we need to add it to the ETSI H.248 profiles in general.  I do not think that H.248 specification can explain these assumptions because it cannot make any statement against the transport layer.  The profile on the other hand does refer to the transport layer and therefor can explain interaction between the H.248 layer and transport layer.

I would like to propose that two assumptions are documented in the TISPAN AGW profile (only applies to UDP transport):

1. The MGC will store the source IP address retrieveed from the first ServiceChange.  All subsequent messages delivered to the MG will use this IP address.

2. The MG will store the source IP address retrieved from the reply to the ServiceChange(1).  All subsequent messages delivered to the MGC will use this IP address.

Note (1) - The MG will use the DNS lookup in order to retrieve the initial IP address to send the first ServiceChange.  This IP address may be different than the IP address returned in the reply to ServiceChange.

Regards,
JanL

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: den 29 april 2005 12:02
To: Jan Lindquist (AL/EAB)
Cc: [email-masked]; [email-masked]
Subject: RE: [Megaco] supplied address and ServiceChangeAddress

Hi Jan,

just an additional comment to the sentence:
"A common
technique with UDP transport of H.248 is to copy the source IP address in the IP header that is in the first ServiceChange from the MG."

I don't know how to handle such a argument. This seems to be an assumption, or a specific interpretation, or a "best current practice" because it is not mentioned in any H.248 Rec. Right?

My question is: do you want to make this implicit assumption as an explicit proposal, e.g., for ETSI H.248 Profiles? ["because the subsequent argumentation bases on this hypothesis"]

Best rgds/Albrecht

                      "Kevin Boyle"

                      etf.org

                      28.04.2005 17:00

There is additional text in that section: "Note that the use of ServiceChangeAddress is not encouraged."  This is advice that ought to be followed.

That aside, to answer your question, the paragraph is discussing the SCAddress parameter alone.  It only indicates that if the SCAddress parameter is present, then the recipient of the SC command must switch to that new address.

Note that if the MGC wishes to change its address, it should use Handoff and the SCMGCID to announce that change.

Kevin

  _____

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jan Lindquist (AL/EAB)
Sent: Thursday, April 28, 2005 10:35 AM
To: [email-masked]
Subject: [Megaco] supplied address and ServiceChangeAddress

Hello,

I would like assistance in the interpretation in the text in H.248 specifically in section 7.2.8 relating to ServiceChangeAddress.  Here is a copy of the text in question:

"The MG may specify the transport ServiceChangeAddress to be used by the MGC for sending messages in the ServiceChangeAddress parameter in the input ServiceChangeDescriptor. The MG may specify an address in the ServiceChangeAddress parameter of the ServiceChange request, and the MGC may also do so in the ServiceChange reply. In either case, the recipient must use the supplied address as the destination for all subsequent transaction requests within the association."

The question relates to the last sentence in the above paragraph.  A common technique with UDP transport of H.248 is to copy the source IP address in the IP header that is in the first ServiceChange from the MG. So all subsequent message to the MG will use that MG IP address.  There is no need for a ServiceChangeAddress.

The question is in the reverse direction.  If I want to change the IP address that the MG should use for any subsequent messages to the MGC. The MGC sends a ServiceChange reply with a new IP address to itself. Shouldn't the MG use that IP address for subsequent messages?

There is a subtle implication in the text that this is acceptable but what does "supplied address" mean.  For ServiceChange coming from the MG the IP address in the IP header is the supplied address.  If this accepted technique for indicating supplied address it is possible to interprete the ServiceChange reply could indicate the supplied address for the MGC.

Regards,
JanL