[Asterisk-Users] DNID in chan_sip.c

[Jesper Dalberg]

Hey list,

I have now been looking at asterisk for a few weeks, trying to solve a
particular problem I have. Let me elaborate.

+------------+
| !asterisk  |  SIP trunk    +-----------+
| Softswitch |---------------| asterisk  |
|            |  class 4 peer +-----------+
+------------+
  | | | |
   users in voip/pstn

The Softswitch takes care of normal call routing, asterisk is to be used
solely for voicemail and for IVR.

So users on the softswitch will have to set up CF to "the magic
voicemail number", which is routed to a SIP trunk leading to the
asterisk. 

VM Logic on the asterisk then has to analyse the A number and the B
numbers to figure out one of 3 cases:

1. There is a mailbox for A - go right to "read my messages"
2. There is a mailbox for B - go right to "leave message"
3. A and B are both unknown, vm wise, authenticate, then go to 1 or
reject.

In case 1, the B number will most likely be identical to the "magic
voicemail number", and is therefore irrelevant.

In case 2, the A number will be someone unknown, and the "magic
voicemail number" will be the C number.

Now, in SIP this is signalled in INVITEs naturally, and a typical invite
for a case 2 scenario could look like.

INVITE sip:<magicvmnum>@<asterisk-ip>:<asterisk-port>;user=phone SIP/2.0
Allow: UPDATE
Call-ID: 000000000000000000006b41f335@<softswitch-ip>
Contact: <sip:ANUM@<softswitch-ip>:<softswitch-sipport>;user=phone>
Content-Type: application/sdp
CSeq: 1561 INVITE
From:
<sip:ANUM@<softswitch-ip>;user=phone>;tag=000000000000000000006b41f336
Max-Forwards: 31
Reason: sip;cause=302
Require: 100rel
To: <sip:BNUM@<asterisk-ip>;user=phone>
User-Agent: Softswitch Agent
Via: SIP/2.0/UDP
<softswitch-ip>:<softswitch-sipport>;branch=z9hG4bK-2FFF
Content-Length: 215

v=0
o=cp10 109870486669 109870486669 IN IP4 <softswitch-ip>
s=SIP Call
c=IN IP4 <softswitch-ip>
t=0 0
m=audio <some RTP port> RTP/AVP 0 8
b=AS:64
a=rtpmap:0 PCMU/8000/1
a=rtpmap:8 PCMA/8000/1
a=ptime:30
a=maxptime:30


The 3 SIP adresses that asterisk requires to decode from the INVITE in
order for me to handle my extension logic are in the 1st headerline, in
the From header and in the To header.

Now finally to the problem.

In chan_sip.c, there is NO reading of the To: header at all on INVITEs,
the information needed to route the call is in the command line (INVITE
blabla), but in order for my logic to work, I need the BNUM from the To
header. 

It would be logical to place the address from the To: header in the DNID
(which is == EXTEN in these cases), would it not? or at least the user
part of the address?

I have written a patch for this, but before i post i want to ask you
guys if you agree that DNID is the place for it? An alternative would be
to place it in "username", which is empty in this case aswell, but that
would require a new variable possibly called SIPUSERNAME.

What do you think? Can stuff get broken by filling stuff into the dnid
field of the channel struct from chan_sip.c in this way?

As far as I see it, we have to agree that not looking at the To: header
at all on INVITEs (not using __get_header anyway) has to be fixed?

brgs,
Jesper Dalberg