This document was generated from CDN thread
Created by: Raymond Ng on 13-11-2009 06:24:48 PM
Hi guys,
We've been developing with the Codian API and came across a fairly strange error. The participant.enumerate method returns the currentState address field (Which is basically the E164/URI we want to use to redial, match against other data and such). It returns only the name up 'till 31 characters, rendering this field useless for redialing (and making comparison just that bit more harder ;-)). We registered the Codian (it's a media2 blade, but our 4520 has the same problem) as H323 to a VCS. We call and get called by endpoints which are H323 registered (with an URI) as wel as SIP (via Interworking).
Any ideas if (and how) this is solvable? Some setting in the MCU? Thanks in advance.
Best Regards,
Henri Brinkhuis & Raymond Ng
VisionsConnected Europe
Subject: RE: [Codian API] Participant.enumerate capping problem
Replied by: Benjamin Isak on 19-11-2009 03:11:30 PM
Hi Raymond,
couldn`t reproduce your described issue, because I do not have such long addesses to call
I think it`s strange, that a xml-string variable is restricted to 31chars...hmm
In the displayName-Field there`s normally stored the same information as in the address field. So maybe
using this field instead of "address" could help you!
Kind Regards,
Benjamin
Subject: RE: [Codian API] Participant.enumerate capping problem
Replied by: Alex Shaw on 20-11-2009 06:49:31 PM
Hi Raymond (and Henri),
This is unfortunately a limitation on the MCU itself and not just part of the API - if you use the web interface to add a participant with a URI (or address of any sort) longer than 31 characters, the MCU will truncate the URI down to 31 characters before attempting to make the call, which will then fail.
This is very much a known limitation, but which release it will be addressed in is still under consideration. I will keep you updated!
Sadly, this will not help as the "displayName" field is also limited to 31 characters.
Yours
Alex.
Subject: RE: [Codian API] Participant.enumerate capping problem
Replied by: Henri Brinkhuis on 22-12-2009 04:41:06 PM
The strange thing is: although it truncates the addresses it still calls the original >31 character addresses, just does not display them properly.
I'm looking forward to a fix on this! We've managed to build a workaround for now but this introduces other problems. Or should I say 'challenges' ;-).
Created by: Raymond Ng on 13-11-2009 06:24:48 PM
Hi guys,
We've been developing with the Codian API and came across a fairly strange error. The participant.enumerate method returns the currentState address field (Which is basically the E164/URI we want to use to redial, match against other data and such). It returns only the name up 'till 31 characters, rendering this field useless for redialing (and making comparison just that bit more harder ;-)). We registered the Codian (it's a media2 blade, but our 4520 has the same problem) as H323 to a VCS. We call and get called by endpoints which are H323 registered (with an URI) as wel as SIP (via Interworking).
Any ideas if (and how) this is solvable? Some setting in the MCU? Thanks in advance.
Best Regards,
Henri Brinkhuis & Raymond Ng
VisionsConnected Europe
Subject: RE: [Codian API] Participant.enumerate capping problem
Replied by: Benjamin Isak on 19-11-2009 03:11:30 PM
Hi Raymond,
couldn`t reproduce your described issue, because I do not have such long addesses to call
I think it`s strange, that a xml-string variable is restricted to 31chars...hmm
In the displayName-Field there`s normally stored the same information as in the address field. So maybe
using this field instead of "address" could help you!
Kind Regards,
Benjamin
Subject: RE: [Codian API] Participant.enumerate capping problem
Replied by: Alex Shaw on 20-11-2009 06:49:31 PM
Raymond Ng:Hi guys,
We've been developing with the Codian API and came across a fairly strange error. The participant.enumerate method returns the currentState address field (Which is basically the E164/URI we want to use to redial, match against other data and such). It returns only the name up 'till 31 characters, rendering this field useless for redialing (and making comparison just that bit more harder ;-)). We registered the Codian (it's a media2 blade, but our 4520 has the same problem) as H323 to a VCS. We call and get called by endpoints which are H323 registered (with an URI) as wel as SIP (via Interworking).
Any ideas if (and how) this is solvable? Some setting in the MCU? Thanks in advance.
Best Regards,
Henri Brinkhuis & Raymond Ng
VisionsConnected Europe
Hi Raymond (and Henri),
This is unfortunately a limitation on the MCU itself and not just part of the API - if you use the web interface to add a participant with a URI (or address of any sort) longer than 31 characters, the MCU will truncate the URI down to 31 characters before attempting to make the call, which will then fail.
This is very much a known limitation, but which release it will be addressed in is still under consideration. I will keep you updated!
Benjamin Isak:
In the displayName-Field there`s normally stored the same information as in the address field. So maybe
using this field instead of "address" could help you!
Kind Regards,
Benjamin
Sadly, this will not help as the "displayName" field is also limited to 31 characters.
Yours
Alex.
Subject: RE: [Codian API] Participant.enumerate capping problem
Replied by: Henri Brinkhuis on 22-12-2009 04:41:06 PM
Alex Shaw:
This is unfortunately a limitation on the MCU itself and not just part of the API - if you use the web interface to add a participant with a URI (or address of any sort) longer than 31 characters, the MCU will truncate the URI down to 31 characters before attempting to make the call, which will then fail.
The strange thing is: although it truncates the addresses it still calls the original >31 character addresses, just does not display them properly.
Alex Shaw:
This is very much a known limitation, but which release it will be addressed in is still under consideration. I will keep you updated!
I'm looking forward to a fix on this! We've managed to build a workaround for now but this introduces other problems. Or should I say 'challenges' ;-).