CONNECTEDLINE(name) ISDN Problem

Home » Asterisk Users » CONNECTEDLINE(name) ISDN Problem
Asterisk Users 2 Comments

When I set CONNECTEDLINE() info for an incoming ISDN call, the calling party sees only CONNECTEDLINE(num) and the name does not get displayed. Some time ago I called a number, where I
did get back a name and a number and everything was displayed correctly. So I think the calling site should basically be able to handle all connected line info.

Looking at a pcap trace of the D-channel data, I see that CONNECTEDLINE(num) maps to the connected number information element and CONNECTEDLINE(name) to the display element. The pcap trace does actually contain my CONNECTEDLINE(name) plus a leading byte with a value of 0xB1 (or
\261 in octal notation). This additional byte is part of the announced string length. Now I
wonder, whether this byte is causing the trouble.

Does anybody know what this leading byte is actually doing there?

jg

2 thoughts on - CONNECTEDLINE(name) ISDN Problem

  • AFAIK, It is some kind of character set code. That byte is intentionally put there for switches that are not Q.SIG or ETSI. Technically, the display IE is only to be sent from the network to the user. So sending it to the network is undefined and switch dependent.

    Connected line name support is fully supported only by Q.SIG since it actually defines how to pass the name. Using the display IE is a defacto standard but is only really going to work in the network to user direction.

    Richard

  • Got it. The single instance where I saw a string on the display was when I called my telco’s technical support. Too bad, I was already dreaming of offering some customers a few nifty features, like greetings, email addresses for further contacts, booking confirmation numbers for hotels, etc…

    I shall still go through all the charset options to see whether there is any effect. Meanwhile I
    managed to get a pcap trace of a calling device and the display element is not at all present. I
    guess they are filtering it out.

    Thank you, Richard.

    jg