Subject: [Megaco] On Wildcarding and 435 Error Code

From: "Jon Rowland" <[email-masked]>
Date: Thu, 13 Jan 2005 15:22:49 -0000

Chaps,

There's been some debate recently about what error codes to use when, and how to deal with wildcarded commands, and some speculation on which wildcarded commands actually make sense.

I'd like to point out that this is an old debate and one that has already been addressed by the addition of section 6.3 "Wildcarding Principles" to the H.248.1 spec. See either:
- The core H.248.1 version 2 (01/2004) spec, which includes that section.
- The H.248.1 version 1 Implementors Guide (01/2004) section 6.11.

Here are the key resolutions to the points we've been discussing:

1) What error code should be used for the below command if the termination is not in any (non-NULL) context?

Transaction=206{
Context=*{AuditValue=line/1{Audit{media,packages,observedevents}}}
}

The answer is given in section 6.3.2. The MG should return error 431 "Termination ID did not match wildcard".

Use of a command such as the one above is vital in such processing as resolving state discrepancies between the MG and the MGC, although to avoid having to deal with the NULL case separately, perhaps something like the following request is better:

Transaction=206{
Context=-{O-AuditValue=line/1{Audit{media,packages,observedevents}}},
Context=*{O-AuditValue=line/1{Audit{media,packages,observedevents}}}
}

Here, if the first command fails, it makes sense to return error 435 "Termination not in specified context" for that part of the transaction. If the termination is in the NULL context then the first command will succeed and the second will fail with erro 431.

2) How do wildcard context IDs (C=*) expand?

There appeared to be some confusion about this. Context ID wildcards are different to termination ID wildcards.

Termination ID wildcards expand as if the same command has been issued for all terminations matching the wildcard in the specified context. NOTE that for terminations that are not in the specified context, no 425 error is generated. A 431 error makes sense if no terminations are in the specified context.

Context ID wildcards expand to the set of contexts that match the terminations referenced by the commands contained in the action. So, for a wildcard context ID with a specific termination as above, the request expands to a single action with the wildcard context ID replaced with the ID of the context the termination is in. No error is generated for all the contexts that the termination is not in. An error is generated if the termination is in the NULL context, or if it doesn't exist - error 431.

If the termination ID is wildcarded as well as the context ID, then the request expands to a set of non-wildcarded actions, one for each matched pair of context ID and termination ID.

3) Subtract "*" from "*".

There was some discussion of the benefits of C=*{S=*}. This again is a very useful command in resynchronising state between the MGC and MG. If, for example, the MGC undergoes a restart with an internal state loss, then it wishes to reset all the terminations on the MGs it is controlling. The MG may have sent a ServiceChange(Disconnected) in this time, but it has not necessarily dropped state from active contexts. The MGC is responsible for this, and it's hardly reasonable to expect the MGC to do this in a non-wildcarded way!

The use of wildcarded subtract is explicitly mentioned in section 7.2.3 of H.248.1.

Again, if no contexts exist on the MG, then error 431 is used.

Hope this helps.

Regards,
Jon.

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