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