Re: IP changeover Procedures

The constitution of a CA (Control Association) is
tightly coupled to the MID (see § 5.2/H.Sup7).

The MID values are missing on your
scenarios.

Please provide that info, too.

Concerning the ServiceChangeMgcID scenario, could you please
refer to § 8/H.Sup7 (§ 8.2) and indicate the difference?

Concerning the ServiceChangeAddress scenario, H.Sup7 is fairly
clear that this parameter may be used for IP interface redirections, during CA
establishment phases (i.e., the CA is NOT yet existent). Again pls refer to
H.Sup7?

Thanks for the reply. So if MGC-active sends a Service
change from IP2 (as IP1 has been down) then shall it will fill
Handoff as reason and new IP address as IP2 in MGCIDtotry field
? If that is the case then shall MG will reply on the new IP
i.e. IP2 ? Kindly help.

A change of address for the
MGC implies a new control association. That does not
necessarily mean that any contexts will be altered; all it
means is that the control association has undergone a
change. It is up to the MGC to clean up anything on the
MG that is out-of-whack. Given that this is really the
same MGC (though the MG cannot possibly know that), the MGC
can choose to take NO action and continue everything as it
is. I will note that the change of interface will take a
non-zero amount of time, so there is the possibility that
messages will be lost. The spec is pretty clear that the
MG has to send replies back to where the command came from, so
there is no way that a change of IP address can not result in
a change of association (see H.248.1, Clause
9).

There is no way the MG could
know that the MGC is the same one after the change of
interfaces. Please see H.248.1 Annex F for normative
details on the ServiceChange procedures that are then used in
the overall procedures in Supplement 7.

Per our Implementation, we need to provide
Interface Redundancy at MGC end, the architecture we
were going to implement is MGC-Active will have 2 IP
interfaces and MGC-Standby will have 2 IP
interfaces.Can someone help in answering following
things:

1. If an Association has been established between
MGC-Active (IP1) and peer MG, and now IP1 of
MGC-Active has gone down and IP-2 of MGC-Active needs
to takeover without breaking the current control
association how can we achieve that?

<<< Per "Updated
Draft ITU-T H.Sup7 “Gateway Control Protocol:
Establishment Procedures for the H.248 MGC-MG Control
Association” (Ed. 0.14)" ServiceChangeAddress field
can be used by MGC to tell new IP address for
remaining association. But the document has suggested
the use of Service Change Address field in the
"Association Establishment Phase".

Another
thing if MGC sends ServiceChangeMethod as "Handoff"
then It would mean that MGC wants a new association
but that is not the case, MGC only wants to change the
address for rest of the association.
>>>

2. If
we use MGCIDtotry field in the ServiceChange command
then MGC will send this command through IP2 (as IP1 of
MGC has been down) so, how will MG got to know that
this request has been sent by MGC that has been
registered on IP1. Shall it recognizes the MGC via MID
?

Re: Specifying audio codec on fixed termination

Tom Taylor <tom111.taylor <at> bell.net>
2009-12-04 16:23:28 GMT

It is legitimate to specify a Local Descriptor for the B channel termination,
indicating which codec is being used.
François Plagnard wrote:
> Hello,
>
>
>
> In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.
>
> In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).
>
> How this audio codec may be indicated by the MGC to the gateway?
>
>
>
> Best regards,
>
>
>
> François Plagnard
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco

Re: Specifying audio codec on fixed termination

Thank you for your answer.
But, now my concern is how to specify an audio codec in a B channel in Local descriptor?
I have found no way to describe it in SDP format contained in Local descriptor (there is no RTP involved here
or any other transport).
Best regards,
François Plagnard
-----Message d'origine-----
De : Tom Taylor [mailto:tom111.taylor <at> bell.net]
Envoyé : vendredi 4 décembre 2009 17:23
À : François Plagnard
Cc : megaco <at> ietf.org
Objet : Re: [Megaco] Specifying audio codec on fixed termination
It is legitimate to specify a Local Descriptor for the B channel termination,
indicating which codec is being used.
François Plagnard wrote:
> Hello,
>
>
>
> In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.
>
> In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).
>
> How this audio codec may be indicated by the MGC to the gateway?
>
>
>
> Best regards,
>
>
>
> François Plagnard
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco

Re: Specifying audio codec on fixed termination

For ISDN-IP on ISDN side you will have physical terminator which the B-channel, for IP side you have to have a
ephemeral terminator created by MG where you use RTP with local/remote descriptor.
If you are trying TDM only calls then the the T1 or E1 with ulaw or alaw should be preconfigured in MG. MGC does
not need to know physical resource configuration of the MG.
May need more information on your implementation.
-Arindam
-----Original Message-----
From: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf Of François Plagnard
Sent: Friday, December 04, 2009 11:58 AM
To: Tom Taylor
Cc: megaco <at> ietf.org
Subject: Re: [Megaco] Specifying audio codec on fixed termination
Thank you for your answer.
But, now my concern is how to specify an audio codec in a B channel in Local descriptor?
I have found no way to describe it in SDP format contained in Local descriptor (there is no RTP involved here
or any other transport).
Best regards,
François Plagnard
-----Message d'origine-----
De : Tom Taylor [mailto:tom111.taylor <at> bell.net]
Envoyé : vendredi 4 décembre 2009 17:23
À : François Plagnard
Cc : megaco <at> ietf.org
Objet : Re: [Megaco] Specifying audio codec on fixed termination
It is legitimate to specify a Local Descriptor for the B channel termination,
indicating which codec is being used.
François Plagnard wrote:
> Hello,
>
>
>
> In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.
>
> In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).
>
> How this audio codec may be indicated by the MGC to the gateway?
>
>
>
> Best regards,
>
>
>
> François Plagnard
>
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco

Re: Specifying audio codec on fixed termination

Tom Taylor <tom111.taylor <at> bell.net>
2009-12-04 19:03:35 GMT

Once upon a time (almost ten years ago) I created an SDP solution for ISDN, but
eventually backed off before it was standardized. I forgot about the need to
specify a transport for the media in the m= line when I answered you today.
Either we would have to carry the necessary changes through as a new AVT profile
or you'll have to use some sort of trick.
François Plagnard wrote:
> Thank you for your answer.
> But, now my concern is how to specify an audio codec in a B channel in Local descriptor?
> I have found no way to describe it in SDP format contained in Local descriptor (there is no RTP involved here
or any other transport).
>
> Best regards,
>
> François Plagnard
>
> -----Message d'origine-----
> De : Tom Taylor [mailto:tom111.taylor <at> bell.net]
> Envoyé : vendredi 4 décembre 2009 17:23
> À : François Plagnard
> Cc : megaco <at> ietf.org
> Objet : Re: [Megaco] Specifying audio codec on fixed termination
>
> It is legitimate to specify a Local Descriptor for the B channel termination,
> indicating which codec is being used.
>
> François Plagnard wrote:
>> Hello,
>>
>>
>>
>> In a gateway between ISDN and IP, B channels on ISDN side are fixed terminations.
>>
>> In some ISDN networks, the audio codec used line may vary per call (often between G.711 A law and mu law).
>>
>> How this audio codec may be indicated by the MGC to the gateway?
>>
>>
>>
>> Best regards,
>>
>>
>>
>> François Plagnard
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Megaco mailing list
>> Megaco <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/megaco
>
>

Re: Specifying audio codec on fixed termination

Hello Francois,
You can use the attributes from H.248.1 Annex C. i.e ACodec from C.1 or
layer1prot from C.9. If you want to carry these in the text encoding use
H.248.15 and a package ID of "anxc" (as defined in Annex C).
Regards, Christian
Tom Taylor wrote:
> Once upon a time (almost ten years ago) I created an SDP solution for
> ISDN, but eventually backed off before it was standardized. I forgot
> about the need to specify a transport for the media in the m= line
> when I answered you today. Either we would have to carry the necessary
> changes through as a new AVT profile or you'll have to use some sort
> of trick.
>
> François Plagnard wrote:
>> Thank you for your answer.
>> But, now my concern is how to specify an audio codec in a B channel
>> in Local descriptor?
>> I have found no way to describe it in SDP format contained in Local
>> descriptor (there is no RTP involved here or any other transport).
>>
>> Best regards,
>>
>> François Plagnard
>>
>> -----Message d'origine-----
>> De : Tom Taylor [mailto:tom111.taylor <at> bell.net] Envoyé : vendredi 4
>> décembre 2009 17:23
>> À : François Plagnard
>> Cc : megaco <at> ietf.org
>> Objet : Re: [Megaco] Specifying audio codec on fixed termination
>>
>> It is legitimate to specify a Local Descriptor for the B channel
>> termination, indicating which codec is being used.
>>
>> François Plagnard wrote:
>>> Hello,
>>>
>>>
>>>
>>> In a gateway between ISDN and IP, B channels on ISDN side are fixed
>>> terminations.
>>>
>>> In some ISDN networks, the audio codec used line may vary per call
>>> (often between G.711 A law and mu law).
>>>
>>> How this audio codec may be indicated by the MGC to the gateway?
>>>
>>>
>>>
>>> Best regards,
>>>
>>>
>>>
>>> François Plagnard
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> _______________________________________________
>>> Megaco mailing list
>>> Megaco <at> ietf.org
>>> https://www.ietf.org/mailman/listinfo/megaco
>>
>>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco
>

The constitution of a CA (Control Association) is
tightly coupled to the MID (see § 5.2/H.Sup7).

The MID values are missing on your
scenarios.

Please provide that info, too.

Concerning the ServiceChangeMgcID scenario, could you please
refer to § 8/H.Sup7 (§ 8.2) and indicate the difference?

Concerning the ServiceChangeAddress scenario, H.Sup7 is fairly
clear that this parameter may be used for IP interface redirections, during CA
establishment phases (i.e., the CA is NOT yet existent). Again pls refer to
H.Sup7?

Thanks for the reply. So if MGC-active sends a Service
change from IP2 (as IP1 has been down) then shall it will fill
Handoff as reason and new IP address as IP2 in MGCIDtotry field
? If that is the case then shall MG will reply on the new IP
i.e. IP2 ? Kindly help.

A change of address for the
MGC implies a new control association. That does not
necessarily mean that any contexts will be altered; all it
means is that the control association has undergone a
change. It is up to the MGC to clean up anything on the
MG that is out-of-whack. Given that this is really the
same MGC (though the MG cannot possibly know that), the MGC
can choose to take NO action and continue everything as it
is. I will note that the change of interface will take a
non-zero amount of time, so there is the possibility that
messages will be lost. The spec is pretty clear that the
MG has to send replies back to where the command came from, so
there is no way that a change of IP address can not result in
a change of association (see H.248.1, Clause
9).

There is no way the MG could
know that the MGC is the same one after the change of
interfaces. Please see H.248.1 Annex F for normative
details on the ServiceChange procedures that are then used in
the overall procedures in Supplement 7.

Per our Implementation, we need to provide
Interface Redundancy at MGC end, the architecture we
were going to implement is MGC-Active will have 2 IP
interfaces and MGC-Standby will have 2 IP
interfaces.Can someone help in answering following
things:

1. If an Association has been established between
MGC-Active (IP1) and peer MG, and now IP1 of
MGC-Active has gone down and IP-2 of MGC-Active needs
to takeover without breaking the current control
association how can we achieve that?

<<< Per "Updated
Draft ITU-T H.Sup7 “Gateway Control Protocol:
Establishment Procedures for the H.248 MGC-MG Control
Association” (Ed. 0.14)" ServiceChangeAddress field
can be used by MGC to tell new IP address for
remaining association. But the document has suggested
the use of Service Change Address field in the
"Association Establishment Phase".

Another
thing if MGC sends ServiceChangeMethod as "Handoff"
then It would mean that MGC wants a new association
but that is not the case, MGC only wants to change the
address for rest of the association.
>>>

2. If
we use MGCIDtotry field in the ServiceChange command
then MGC will send this command through IP2 (as IP1 of
MGC has been down) so, how will MG got to know that
this request has been sent by MGC that has been
registered on IP1. Shall it recognizes the MGC via MID
?

1. MGC makes an association with peer gateway.It fills MID as
xxx <at> yyy.com and fills ServiceChangeAddress as IP1.[[Schwarz, Albrecht]] Did the MG accept the request? I.e.,
is there an established CA?

2. Now IP1 goes down at MGC end.

3. MGC is now sending a ServiceChange Message (Method Handoff) from
IP2 with MID as xxx <at> yyy.com and fills MGCIDtotry field with
IP2.[[Schwarz, Albrecht]] The H.248 Message for
the MGC_1-initiated Handoff request is identified by "MID as xxx <at> yyy", but
which MID value carries the ServiceChangeMgcID? Really
ServiceChangeMgcID = 'IP2'?

So shall MG be able to handle the request and will it reply to IP2
?[[Schwarz, Albrecht]] only if the indicated
secondary MGC is listed in the MG database of MGC instances, see
Table 2/H.Sup7

The constitution of a CA
(Control Association) is tightly coupled to the MID (see §
5.2/H.Sup7).

The MID values are missing on
your scenarios.

Please provide that info,
too.

Concerning the ServiceChangeMgcID scenario, could
you please refer to § 8/H.Sup7 (§ 8.2) and indicate the
difference?

Concerning the ServiceChangeAddress scenario, H.Sup7 is
fairly clear that this parameter may be used for IP interface
redirections, during CA establishment phases (i.e., the CA is NOT yet
existent). Again pls refer to H.Sup7?

Thanks for the reply. So if MGC-active sends a
Service change from IP2 (as IP1 has been down) then
shall it will fill Handoff as reason and new IP
address as IP2 in MGCIDtotry field ? If that is the
case then shall MG will reply on the new IP i.e. IP2 ?
Kindly help.

A change of address for the MGC
implies a new control association. That does
not necessarily mean that any contexts will be
altered; all it means is that the control
association has undergone a change. It is up
to the MGC to clean up anything on the MG that is
out-of-whack. Given that this is really the
same MGC (though the MG cannot possibly know that),
the MGC can choose to take NO action and continue
everything as it is. I will note that the
change of interface will take a non-zero amount of
time, so there is the possibility that messages will
be lost. The spec is pretty clear that the MG
has to send replies back to where the command came
from, so there is no way that a change of IP address
can not result in a change of association (see
H.248.1, Clause 9).

There is no way the MG could
know that the MGC is the same one after the change
of interfaces. Please see H.248.1 Annex F for
normative details on the ServiceChange procedures
that are then used in the overall procedures in
Supplement 7.

Per our Implementation, we need to provide
Interface Redundancy at MGC end, the
architecture we were going to implement is
MGC-Active will have 2 IP interfaces and
MGC-Standby will have 2 IP interfaces.Can
someone help in answering following
things:

1. If an Association has been established
between MGC-Active (IP1) and peer MG, and now
IP1 of MGC-Active has gone down and IP-2 of
MGC-Active needs to takeover without breaking
the current control association how can we
achieve that?

<<< Per "Updated
Draft ITU-T H.Sup7 “Gateway Control Protocol:
Establishment Procedures for the H.248 MGC-MG
Control Association” (Ed. 0.14)"
ServiceChangeAddress field can be used by MGC to
tell new IP address for remaining association.
But the document has suggested the use of
Service Change Address field in the "Association
Establishment Phase".

Another thing if MGC
sends ServiceChangeMethod as "Handoff" then It
would mean that MGC wants a new association but
that is not the case, MGC only wants to change
the address for rest of the association.
>>>

2. If we use MGCIDtotry
field in the ServiceChange command then MGC will
send this command through IP2 (as IP1 of MGC has
been down) so, how will MG got to know that this
request has been sent by MGC that has been
registered on IP1. Shall it recognizes the MGC
via MID ?