Subject: RE: [Megaco] question about extension in serviceChangeParm

From: [email-masked]
Date: Fri, 16 Apr 2004 17:45:33 +0800

I think the extensionParameter in Megaco need not be conformance with the
restriction of At Most Once,the extensionParameter is available for
different vender,it is uncertainty. if it is at most once ,the use of the
extensionParameter  will be restricted.maybe later the extensionParameter
will be the Confirmed parameter if the extensionParameter  is accepted by
people .
BTW:
rfc3525 page 122  have a case
  ; at-most-once except for extensionParameter
 thanks and regards!
 liuqifeng

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

---

From: "atto" <[email-masked]>
Date: Sun, 18 Apr 2004 10:21:19 +0800

hi,
It is really a good suggestion, and can make megaco more expansible.
I hope it could be a part of next version.
but now, if more than one extension in serviceChangeParm,
there will be problem when interoperate with stacks that strictly comply
with protocol.

b.r.
atto

---

From: "atto" <[email-masked]>
Date: Sun, 18 Apr 2004 10:21:19 +0800

hi,

b.r.
atto

---

From: Christian Groves <[email-masked]>
Date: Mon, 19 Apr 2004 11:45:15 +1000

Hello,

H.248.1v2 states:
; each parameter at-most-once
; at most one of either serviceChangeAddress or serviceChangeMgcId but
; not both
; serviceChangeMethod and serviceChangeReason are REQUIRED
serviceChangeParm    = (serviceChangeMethod / serviceChangeReason /
                        serviceChangeDelay / serviceChangeAddress /
                        serviceChangeProfile / extension / TimeStamp /
                        serviceChangeMgcId / serviceChangeVersion /
                        auditItem)

So there's only one extension paramter.

The parameter is basically an  (octet)string that you can put vendor specific 
data in. You can format it however you like so if you want to carry multiple 
values then you carry these in the data field and seperate then in some vendor 
specific way.

I would discourage the general use of this field as it does harm interoperability.

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 19 Apr 2004 11:45:15 +1000

Hello,

H.248.1v2 states:

Regards, Christian