Skip to main content

Alert Info for internal calls is not usable for snom phones

Posted by reventix on Tue, 10/06/2009

Hello,

today I found out, that the "Alert Info for internal calls" is not usable for snom phones.

The Alert-Info header has to look like the following:
Alert-Info: ;info=alert-group;x-line-id=0

The problem is that TL puts <> around the user input:
Alert-Info: <;info=alert-group;x-line-id=0>

IMHO it would be better if the <> would not be wrapped around the user input

Regards
Bastian


Submitted by eeman on Tue, 10/06/2009 Permalink

The RFC specifically requires Alert-info to be quoted inside right angle and left angle brackets. Improperly formatted packets WILL NOT traverse a tool like sipproxd using libosip.so as their sip library. It is because of non RFC-reading code suggesters that the sipproxd community did the unthinkable; any useragent of Asterisk will IMMEDIATELY remove Alert-Info headers from the sip invites regardless of proper format. They got tired of fielding the complaints that invites were not making it to the phones because libosip was not parsing; all as a result of some moron contributing to freepbx without first checking with the RFC to make sure its correct.

Alert-Info = "Alert-Info" HCOLON alert-param

alert-param = LAQUOT absoluteURI RAQUOT

Submitted by eeman on Tue, 10/06/2009 Permalink

the whole purpose of 'Alert-Info for internal calls' is to change the ring type so internal calls have a different ringing than external calls. This may not even be possible for snom phones. Your info definitely gives me the beginnings of a checklist as to why snom phones fail muster:

1. incapable of performing a blind transfer

2. do not properly adhere to the RFC on header fomatting.

On polycom phones there are multiple alert levels you can define and several pre-defined

Visual

Internal

External

Auto Answer

Ring Answer

Emergency

Custom 1

Custom 2

Custom 3

Custom 4

simply sending a header

Alert-Info:

will tell the phone how to behave based on predefined values in sip.cfg and/or re-defined in polycom_local.cfg

linksys phones are similar:

Alert-Info:

Submitted by cbbs70a on Tue, 10/06/2009 Permalink

I spent a lot of time developing a ringtone feature for the user portal and I did it first for a Snom 320.

Users can select a ringtone for a specific callerid, or select a ringtone for a group of callers such as friends, family, internal, external, blah, blah, blah and I have no problem with it. I modified the dial plan and select a ringtone via http like so:

exten => s,n,SIPAddHeader("Alert-Info:") where ${defaultrt} is the name of the ringtone .wav file.

Works like a charm. Always has. Don't know what you guys are talking about. I hope this helps.

FSD

Submitted by reventix on Fri, 10/09/2009 Permalink

I think you misinterpret the RFC.

On the RFC3261 (http://www.ietf.org/rfc/rfc3261.txt), page 226 you can see the following definition:

[...]

Alert-Info = "Alert-Info" HCOLON alert-param *(COMMA alert-param)

alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param )

[...]

There you can see that only the URI-Part should be wrapped with <>.

Also your comments about the snom phones are not true. E.g. blind transfer works perfect.

Back to the problem.

I don't want to set external ring tones. I just want to set set the internal ring tones. See: http://wiki.snom.com/Settings/Alert_Info_Ringer

The problem could easily resolved by removing the automatic <> around the user input. In this case the user has to place the brackets by themselves.

Regards

Bastian

Submitted by eeman on Fri, 10/09/2009 Permalink

right, and the problem is the user is not putting the brackets in 99% of the time and thereby breaking proper format. So much so the case, that an entire development community has decided that when useragent=asterisk they surgically remove the alert-info tag entirely. I hear what you are saying but to remove the brackets from the dialplan in favor of requiring the user to do it manually would create 2 issues

1) existing installations using it would stop working unexpectedly and likely generate a lot of work for admin's until they discovered why the change occured, in which case an MTE installation would require hundreds of changes for each tenant.

2) users sending their traffic through siproxd who had previously redefined their useragent to make distinctive ringing work through a proxy suddenly have total call failure for a bad formatted sip message.

perhaps instead its better to ask for a 2nd field called generic-parameters and then modify userexten-base in this fashion:

exten => s,n,ExecIf($[$[${LEN(${CALLERID(num)})} < 7] & $[${DB_EXISTS(TL/TENANT/${tenant}/usedistinctring)}]]?SIPAddHeader(Alert-Info: <${DB(TL/TENANT/${tenant}/intalertinfo)}>${DB(TL/TENANT/${tenant}/intalertinfo-generic)}))