[Home]

Summary:ASTERISK-01224: BOUNTY $50 to add dnid and rdnis support to chan_sip
Reporter:ewieling (ewieling)Labels:
Date Opened:2004-03-16 17:48:54.000-0600Date Closed:2004-09-25 02:54:38
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I am offering a $50 bounty for a patch that is accepted into the Digium Asterisk CVS before May 1 2004 to make RDNIS and DNID work for SIP calls.

This information must be able to be be accessed via ${RDNIS} and ${DNID} in extensions.conf.  This feature is already in chan_zap.

Payment will be made via paypal or or check via first class mail.
Comments:By: ewieling (ewieling) 2004-03-17 13:32:31.000-0600

DNID and RDNIS are basically ISDN terms.  I believe that DNID would be the same as the extension the call is going to, the RDNIS would be the extension that forwarded the number.  Then a call comes into a Cisco phone and the phone is on DND or any type of call forwarding the phone respondes with a SIP 302 message telling Asterisk where the call should be sent.  Without RDNIS variable available in the dial plan there's no way to know what the forwarding extension was.  This is important since the Cisco has a button for "messages" aka Voicemail.  If you program the button to be the number for VoiceMailMain then when the phone forwards calls to that number callers will be asked to login to voicemail and not to just leave a message for the called person.  With RDNIS I can do stuff in the dial plan to do the "right thing".

From IRC:

<Connor-> Wouldn't DNID be the new # it's forwarded too?
<Connor-> and RDNIS be the # that forwarded it ?
<citats> ManxPower: DNID should be the extension the call is being forwarded too... and RDNIS would be the extension that the call was sent to but did the call forwarding

Basically when a call is forwarded (using a SIP 302 response) RDNIS should be set to extension/number that did the forwarding.

DNID should always be set the the number the call is going to.

Also see http://www.cisco.com/en/US/products/hw/vcallcon/ps2027/products_implementation_design_guide_chapter09186a008007e5ff.html Table 2-3

I think chan_zap has DNID and RDNIS features already so you can use that as a reference if you want.
By: Olle Johansson (oej) 2004-03-17 13:53:27.000-0600

Could I see a SIP debug output from a 302 transaction?
By: ewieling (ewieling) 2004-03-17 13:58:54.000-0600

The small function in chan_sip.c that handles 302 messages should have the original extension available to it in the channel structure.

Sip read:
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 209.16.70.122:5060;branch=z9hG4bK6ac6253e
From: "Eric Wieling" <sip:2111@209.16.70.122>;tag=as2152e047
To: <sip:mmayer@208.164.150.160:1320>;tag=2273601550
Call-ID: 0bfae5e77c7597f9025149a34f8aa566@209.16.70.122
CSeq: 102 INVITE
Contact: <sip:3009@voip-1.stirlingprop.com:5060;user=phone>
Diversion: <sip:mmayer@208.164.150.160:1320>;reason="unavailable"
Server: Cisco-CP7905/1.01-030807A
Allow: ACK, BYE, CANCEL, INVITE, NOTIFY, OPTIONS, REFER, REGISTER
Content-Length: 0
By: Olle Johansson (oej) 2004-03-17 15:36:45.000-0600

The whole 302 handling in the SIP channel in combination with app/dial is broken. If the SIP call results in a 302 redirect to another SIP domain, the domain is lost. Even if it wasn't, app_dial couldn't handle it properly today.
Setting variables in the function is lost, because what you're looking for is not only setting them in thte first call, but preserving them in the new call.

Ugly, this is, code supporting 302, yoda said :-)
By: Olle Johansson (oej) 2004-03-17 16:12:50.000-0600

Patch 0000730 solves most of the ugliness with 302 redirects in app_dial and chan_sip.

...gotta hunt the call legs.
By: Olle Johansson (oej) 2004-03-17 16:34:38.000-0600

I can set the RDNIS for the first call, that call is hungup in app_dial, so we got to preserve it for the new call in app_dial. Tried, but just got core dumps... Will try again later this week. Path 730 is the base for my trials.
By: ewieling (ewieling) 2004-03-17 17:33:59.000-0600

If it was *easy* I would have done it myself and saved the $50. 8-)
By: Brian West (bkw918) 2004-03-17 21:30:38.000-0600

the question is what does the RFC say on the sip side.
By: ewieling (ewieling) 2004-03-17 22:39:41.000-0600

I think you might be confused about what I'm looking for.  When a call comes into the Cisco and I press the ToVM button (or the phone is set for DND or Call Forwarding) the Dial app is NOT called.  Here is the output from my CLI:  I am NOT talking about being on a call and THEN doing a transfer.  That would be tougher and not what this bounty is for.

 -- Executing Dial("IAX2[btel@btel]/4", "SIP/mmayer|20") in new stack
   -- Called mmayer
   -- SIP/mmayer-01f7 is ringing
   -- Got SIP response 302 "Moved Temporarily" back from 208.164.150.160
   -- Now forwarding IAX2[btel@btel]/4 to '3009@toll-access' (thanks to SIP/mmayer-01f7)
   -- Executing NoOp("Local/3009@toll-access-b9cf,2", "EXTEN=3009 CALLERID="Eric Wieling" <2111> DNID= RDNIS=") in new stack
   -- Executing VoiceMailMain("Local/3009@toll-access-b9cf,2", "") in new stack
   -- Local/3009@toll-access-b9cf,1 answered IAX2[btel@btel]/4
By: Mark Spencer (markster) 2004-03-18 00:53:59.000-0600

See if that's what you want.
By: Olle Johansson (oej) 2004-03-18 02:42:09.000-0600

Bkw: The SIP rfc:s says read the whole SIP uri, we're not doing that, we're ignoring the domain part now.

Ewieling: In your example your executing DIAL to start with and it's app_dial that handles the forwaring part as well. The log message "Now forwarding" is app_dial. That's why we need to set this in app_dial, if I understand it correctly. And while investigating how Asterisk handles SIP forwarding, I found some other problems that patch 730 took care of somewhat.
By: ewieling (ewieling) 2004-03-18 11:47:58.000-0600

kram, no that did not fix the problem.  chan_sip never sets dnid or rdnis on a 302 Redirect, so the change in app_dial has no effect at this time.  In fact the sip_pvt structure doesn't have a place to store dnid (it does have a place to store rdnis)
By: Mark Spencer (markster) 2004-03-18 12:33:01.000-0600

The idea was to set rdnis based on the *called extension*.  That way it would be generally applicable and not need something specific for SIP.  However, if you truly want RDNIS to be the *callerid* and not the *extension* then it will have to be done in SIP itself.

Which is it you want?
By: ewieling (ewieling) 2004-03-18 13:19:01.000-0600

Extension 2111 calls extension 3024.  Extension 3024 (Cisco 7905G) rings.  The person at extension 3024 presses the "ToVM" button on their phone.  The Cisco 7905G sends a 302 Redirect to Asterisk.  Asterisk sends the call to extension 3009 (the number configured on the Cisco as the voice mail number).  RDNIS should contain 3024 (i.e. the number of the redirecting station).  In 0.7.2 and in CVS latest (after Mark's patch) ${RDNIS} and ${DNID} in the dialplan is empty.  Come to think of it, would using the Macro() be clearing the variables?

Connected to Asterisk CVS-03/18/04-10:26:42 currently running on voip-1 (pid = 29236)
Asterisk Ready.
   -- Remote UNIX connection
   -- Accepting AUTHENTICATED call from 208.164.150.160, requested format = 1024, actual format = 1024
   -- Executing Macro("IAX2[btel@btel]/6", "std-exten|SIP/mmayer|20") in new stack
   -- Executing Dial("IAX2[btel@btel]/6", "SIP/mmayer|20") in new stack
   -- Called mmayer
   -- SIP/mmayer-9ff0 is ringing
   -- Got SIP response 302 "Moved Temporarily" back from 208.164.150.160
   -- Now forwarding IAX2[btel@btel]/6 to '3009@toll-access' (thanks to SIP/mmayer-9ff0)
   -- Executing NoOp("Local/3009@toll-access-fb4f,2", "EXTEN=3009 CALLERID="Eric Wieling" <2111> DNID= RDNIS=") in new stack
   -- Executing VoiceMailMain("Local/3009@toll-access-fb4f,2", "") in new stack
   -- Local/3009@toll-access-fb4f,1 answered IAX2[btel@btel]/6
 == Spawn extension (macro-std-exten, s, 2) exited non-zero on 'Local/3009@toll-access-fb4f,2<ZOMBIE>' in macro 'std-exten'
 == Spawn extension (local-access, 3024, 1) exited non-zero on 'Local/3009@toll-access-fb4f,2<ZOMBIE>'
   -- Playing 'vm-login' (language 'en')
   -- Got SIP response 302 "Moved Temporarily" back from 208.164.150.160
 == Spawn extension (toll-access, 3009, 2) exited non-zero on 'IAX2[btel@btel]/6'
   -- Hungup 'IAX2[btel@btel]/6'
voip-1*CLI>

extensions.conf for 3009:

exten => _XX09,1,NoOp(EXTEN=${EXTEN} CALLERID=${CALLERID} DNID=${DNID} RDNIS=${RDNIS})
exten => _XX09,2,VoicemailMain()
By: Olle Johansson (oej) 2004-03-18 14:00:31.000-0600

Kram: Need your help in this. Even if I store something in sip_pvt->rdnis or sip_pvt->owner->rdnis I can't read it from the ${RDNIS} in the final extension. RDNIS got to be extension (or when we get a forward from any SIP device out there, the SIP uri of that device).
By: ewieling (ewieling) 2004-03-18 14:11:20.000-0600

A SIP URI in ${RDNIS} would 1) not be useful to me 2) not be compatable with RDNIS in the PRI ISDN world and 3) be totally useless for the needs of the dialplan.  I want the Redirected NUMBER Identification not the Redirected SIP URI Identification.  We want things like RDNIS, DNID, CAUSECODE, etc to be NOT channel specific. Recirecting a SIP 302 to a URI just complicates things.  Make it redirect to an extension using chan_local and let the dial plan deal with routing (or not routing) the call.
By: Mark Spencer (markster) 2004-03-18 15:07:12.000-0600

Okay, try now with latest CVS (head, not stable).
By: Olle Johansson (oej) 2004-03-18 15:34:03.000-0600

Mark, I corrected that part yesterday in my test environment and i can't get it to work... maybe I'm doing something wrong in the SIP channel.

Try something like this this:
exten=>olle,1,dial(SIP/oej@edvina.net)
exten=>skrep,1,noop(Rdnis: ${RDNIS})

You'll get a redirect to an extension. If I configure that extension to show ${RDNIS} I still get nothing.

Ewieling: SIP phone *ALWAYS* redirect to URI:s whether you want it or not. See your SIP packet above. Your extension is part of an URI. The example on Cisco.com you forwarded to me uses SIP and URI's and still call it RDNIS.
By: Mark Spencer (markster) 2004-03-18 15:39:19.000-0600

The RDNIS is only available in the calling (Local) channel, not in the primary one, obviously, but i forgot to populated it from one side of chan_local to the other.  try now.
By: ewieling (ewieling) 2004-03-18 16:24:11.000-0600

Mark's CVS updates have fixed the RDNIS issue.  All that's left is DNID and we can close this and pay the bounty.
By: ewieling (ewieling) 2004-03-18 16:56:51.000-0600

The exceprt from my dialplan now works:

exten => _XX09,1,GoToIf($[X${RDNIS} != X]?${EXTEN},4)
exten => _XX09,2,VoicemailMain()
exten => _XX09,3,Hangup
exten => _XX09,4,VoiceMail(u${RDNIS})
exten => _XX09,5,Hangup
By: Mark Spencer (markster) 2004-03-18 19:41:14.000-0600

DNID is just ${EXTEN}
By: ewieling (ewieling) 2004-03-18 20:54:26.000-0600

I realized that after I posted the bounty.  Can you tell me the reason that there IS a ${DNID} variable documented in README.variables?
By: Mark Spencer (markster) 2004-03-18 20:55:26.000-0600

DNID is the original incoming number from the PSTN if supplied.  Only applies to E&M and some PRI channels.
By: Mark Spencer (markster) 2004-03-18 22:33:20.000-0600

Added in CVS head