Controling the From header of SIP Options messages

Asterisk Asterisk Support
1

I am noticing a strange header in SIP Options messages that Asterisk periodically sends to it’s peers when qualify is set to yes in sip.conf. This is an example (IP address of the Asterisk is 192.168.99.221, IP address of peer 106 is 192.168.99.47):

Reliably Transmitting (no NAT) to 192.168.99.47:5060:
OPTIONS sip:106@192.168.99.47:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 192.168.99.221:5060;branch=z9hG4bK2524e92b;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@192.168.99.221>;tag=as6c010e2d
To: <sip:106@192.168.99.47:5060;transport=udp>
Contact: <sip:asterisk@192.168.99.221>
Call-ID: 15f8292f25194d76258c5902682604ac@192.168.99.221
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 1.6.2.8
Date: Fri, 07 Jan 2011 18:32:51 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO
Supported: replaces, timer
Content-Length: 0

TELOS-IP-PBX*CLI> 
<--- SIP read from UDP:192.168.99.47:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.99.221:5060;branch=z9hG4bK2524e92b;rport=5060;received=192.168.99.221
From: "asterisk" <sip:asterisk@192.168.99.221>;tag=as6c010e2d
To: <sip:106@192.168.99.47:5060;transport=udp>;tag=2935947004
Call-ID: 15f8292f25194d76258c5902682604ac@192.168.99.221
CSeq: 102 OPTIONS
Allow:  INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, PRACK, SUBSCRIBE, INFO
Server: Aastra 57i/2.5.2.30
Supported: gruu, timer, 100rel, replaces, path
Content-Length: 0

What I would like to do is to change the From header of the SIP Options message from

to

Is this possible with setting of any parameters in sip.conf? I did quite a lot of research, but did not find anything usefull.

This is the current configuration of the SIP Friend:

[106]
type=friend
secret=XXXX
callerid="My Name"<106>
mailbox=106@default
call-limit=2
context=internal_calls
host=dynamic
disallow=all
allow=alaw
allow=ulaw
pickupgroup=1
callgroup=1
dtmfmode=inband
qualify=yes
2

Negative. There isn’t a configuration option to accomplish this.

3

Why do you think this feature is needed?

4

To be totally honest, I do not know the RFC definition for the form of SIP Option message, but I would guess that extension “asterisk” in the From header is not a part of the definition :wink:

Usually the extension “asterisk” is used when the needed parameter is missing in the definition of a SIP peer (“asterisk” is usually the default value), so I thought that there is also a parameter for the SIP peer that is used in the SIP Option message. It is a bit illogical to me that the peer for which the SIP Option message is sent for is not included in the From header, instead extension “asterisk” is used. But apparently the devices or users don’t have a problem with it, so I guess it’s ok :smile:.

Thanks for clearing this up.