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
the whole purpose of
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:
I spent a lot of time
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
I think you misinterpret the
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
right, and the problem is the
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)}))
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