[Home]

Summary:ASTERISK-04884: Asterisk Calls VoiceXML Application Deployed on SipXVxml -- in Asterisk 1.0.9 -- chan_sip.c
Reporter:Cokorda Raka Angga Jananuraga (rakabali78)Labels:
Date Opened:2005-08-23 23:01:52Date Closed:2011-06-07 14:10:40
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip.c
Description:I think I found (and fixed) a bug in chan_sip.c (asterisk 1.0.9). The bug and the fix is explained in detail on my blog: http://www.jroller.com/page/donraka?entry=asterisk_calls_voicexml_application_deployed

I still need to test this solution with some "non-trivial" voicexml applications deployed on sipxvxml.

Best regards,
Raka (http://www.jroller.com/page/donraka)
Comments:By: Michael Jerris (mikej) 2005-08-23 23:48:43

From the blog, SipXVxml is looking for the tag inside the <>, like this:

To: <sip:100-AT-90.0.0.15:5100;play=http%3A%2F%2F90.0.0.15%3A9000%2Faxis%2Fa.vxml%3Fp%3D1>

but asterisk is sending it like this:

To: <sip:100-AT-90.0.0.15:5100>;play=http%3A%2F%2F90.0.0.15%3A9000%2Faxis%2Fa.vxml%3Fp%3D1


By: Michael Jerris (mikej) 2005-08-24 00:07:50

the reference draft on this is:

http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-11.txt
By: twisted (twisted) 2005-08-24 00:10:32

seems valid..  according to this draft (which oddly enough expires today), vxml parameters should end up before uri parameters in the uri.

According to rfc3261 in section 20.10, which relates to the contact header, but explicitly states that it also applies to the To and From header fields, uri parameters belong within the <>'s when the <>'s are appropriate.

According to the draft at http://www.ietf.org/internet-drafts/draft-burger-sipping-netann-11.txt, in section 4.1, vxml parameters are to be treated as uri parameters as stated in rfc3261 section 6.
By: Michael Jerris (mikej) 2005-08-24 00:12:40

so that being said, we need to verify the behavior in cvs head, and a patch against cvs head to correct the issue.
By: twisted (twisted) 2005-08-24 00:12:56

The only problem i see is that you patched 1.0.9 and not cvs-head.  Please attach your patches here in unified diff format, for any/all branches you are patching.

Also, make sure you have a disclaimer on file with digium if this is a non-trivial fix.
By: twisted (twisted) 2005-08-24 00:15:28

not a major bug.  minor bug since this doesn't even technically have an rfc yet for vxml, and since it does not hinder normal operation.
By: Cokorda Raka Angga Jananuraga (rakabali78) 2005-08-24 00:42:38

Sorry, I forgot to turn off the email scrambler plugin for that blog entry. It made it less accruate (the plugin changes @ to AT and . to DOT). Now I've turned it off.
By: Olle Johansson (oej) 2005-08-24 02:00:04

There is another patch in the bug tracker for adding options within the URI.
By: Olle Johansson (oej) 2005-08-24 02:02:09

I have uri encoding functions for the dialplan in another bug report.
By: Olle Johansson (oej) 2005-08-24 02:03:35

With those two patches, you can do what you want. Please try and confirm.
By: Cokorda Raka Angga Jananuraga (rakabali78) 2005-08-24 19:05:40

Hi,

I'm trying to apply the patch I did on chan_sip.c that belongs to Asterisk 1.0.9's to the one that belongs to CVS head (rev 1.814).... followed by make, make install, and run the asterisk.

I ran into a problem. Seems like the asterisk doesn't read the VXML_URL var that I specify in the extension.conf, like this:

exten => 4781,1,SetVar(VXML_URL=play=http%3A%2F%2F90.0.0.15%3A9000%2Faxis%2Fa.vxml%3Fp%3D1)

From comparing the sources of chan_sip.c in asterisk release 1.9 and the one in CVS head, I found out that the way of "getting the value of VXML_URL" has been slightly modified.

Previously it was (started on line 1460):
....
AST_LIST_TRAVERSE(headp,current,entries) {
 /* Check whether there is a VXML_URL variable */
 if (strcasecmp(ast_var_name(current),"VXML_URL")==0)
 {
   vxml_url = ast_var_value(current);
 }
....                

Now it is (started on line 1911):
....
AST_LIST_TRAVERSE(headp,current,entries) {
 /* Check whether there is a VXML_URL variable */
 if (!options.vxml_url && !strcasecmp(ast_var_name(current),"VXML_URL")) {
   options.vxml_url = ast_var_value(current);
 }
....


I don't know if that change has anything to do with the problem I'm having. I tried debugging it with DDD, but the "testing window" was too small -- the client (kiax) hanged-up too fast, before I could figure out what might be the cause of this problem. I've tried setting very high timeout in the extension.conf (when calling Dial), but it didn't help.

I attach the modified chan_sip.c (based on the one I downloaded from CVS Head). Here's the link: http://bugs.digium.com/file_download.php?file_id=7115&type=bug

Could you please help analyze the situation?

Best regards and thanks in advance,
-----------------------------------
Cokorda Raka (rakabali78@yahoo.com)
http://www.jroller.com/page/donraka
Simitel.com - Mexico D.F - 11700
-----------------------------------
By: Olle Johansson (oej) 2005-08-25 00:50:08

...could you please try the existing patches that I believe will solve your problem? I think they are cleaner and more generic.
By: Cokorda Raka Angga Jananuraga (rakabali78) 2005-08-25 19:18:22

Hi,

Ok. I just re-downloaded the source from CVS head, compile, and test.

I have this in my extension.conf:
---
exten => 4781,1,Set(VXML_URL=play=http%3A%2F%2F90.0.0.70%3A8080%2FTracker%2Finit.vxml%3Fp%3D1)
exten => 4781,2,Dial(SIP/100@90.0.0.15:5100,999999999999,t)
---
(oh, I just found out that SetVar has been deprecated, asterisk -- on my first trial -- suggested me to use Set instead).

Ok, so the calling sipxvxml test didn't work. Here's the output on the asterisk console:

SIP Debugging enabled
*CLI>     -- Accepting AUTHENTICATED call from 90.0.0.70:
      > requested format = gsm,
      > requested prefs = (),
      > actual format = gsm,
      > host prefs = (),
      > priority = mine
   -- Executing Set("IAX2/raka_iax@raka_iax-2", "VXML_URL=play=http%3A%2F%2F90.0.0.70%3A8080%2FTracker%2Finit.vxml%3Fp%3D1") in new stack
   -- Executing Dial("IAX2/raka_iax@raka_iax-2", "SIP/100@90.0.0.15:5100|999999999999|t") in new stack
We're at 90.0.0.15 port 19322
Answering/Requesting with root capability 0x2 (gsm)
Answering with capability 0x4 (ulaw)
Answering with capability 0x8 (alaw)
Answering with non-codec capability 0x1 (telephone-event)
12 headers, 12 lines
Reliably Transmitting (no NAT) to 90.0.0.15:5100:
INVITE sip:100@90.0.0.15:5100 SIP/2.0
Via: SIP/2.0/UDP 90.0.0.15:5060;branch=z9hG4bK22f8c627
From: "raka_iax" <sip:12345678@90.0.0.15>;tag=as4dbb8864
To: <sip:100@90.0.0.15:5100>
Contact: <sip:12345678@90.0.0.15>
Call-ID: 2f0937e21bba0ab56f8bbd6665188ae9@90.0.0.15
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Fri, 26 Aug 2005 00:16:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: 257

v=0
o=root 28001 28001 IN IP4 90.0.0.15
s=session
c=IN IP4 90.0.0.15
t=0 0
m=audio 19322 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

---
Aug 25 19:16:57 WARNING[28001]: chan_sip.c:959 __sip_xmit: sip_xmit of 0x9e29518 (len 720) to 90.0.0.15 returned -1: Bad file descriptor
   -- Called 100@90.0.0.15:5100
Retransmitting #1 (no NAT) to 90.0.0.15:5100:
INVITE sip:100@90.0.0.15:5100 SIP/2.0
Via: SIP/2.0/UDP 90.0.0.15:5060;branch=z9hG4bK22f8c627
From: "raka_iax" <sip:12345678@90.0.0.15>;tag=as4dbb8864
To: <sip:100@90.0.0.15:5100>
Contact: <sip:12345678@90.0.0.15>
Call-ID: 2f0937e21bba0ab56f8bbd6665188ae9@90.0.0.15
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Fri, 26 Aug 2005 00:16:57 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: 257

v=0
o=root 28001 28001 IN IP4 90.0.0.15
s=session
c=IN IP4 90.0.0.15
t=0 0
m=audio 19322 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
By: Cokorda Raka Angga Jananuraga (rakabali78) 2005-08-25 19:35:38

Ok,

Now I re-copied the modified chan_sip.c (http://bugs.digium.com/file_download.php?file_id=7115&type=bug), recompile, and test.

Still failed. The log is the same as the one in my previous note.

The vxml_url, on line 4423, is always null (0x0).

How do we specify VXML_URL in extension.conf on this CVS head version of asterisk?

Best regards,
Raka
By: Olle Johansson (oej) 2005-08-26 08:14:03

Please try CVS head with the patches I mentioned above. These do not involve using VXML_URL at all.
By: Cokorda Raka Angga Jananuraga (rakabali78) 2005-08-26 13:14:08

Hi,

I just applied the patch you mentioned (to the source I re-downloaded from CVS head), and modfied my extension.conf. Now it looks like:
---
exten => 4781,1,SetVar(_URI_OPTIONS=play=http%3A%2F%2F90.0.0.70%3A8080%2FTracker%2Fvxml%2Ftracker.vxml%3Fp%3D1)
exten => 4781,2,Dial(SIP/100@90.0.0.15:5100,999999999999,t)
---

Well, the appending of "play=..." seemed to work. But I'm getting new problem (maybe unrelated to this bug entry). I mean, the asterisk never gets an OK for the INVITE it sent (I paste the log at the end of this note). So it retransmit and retrasnmit, and retransmit...

By comparing the invite message sent by the CVS version of asterisk and 1.0.9, I notice that the CVS version doesn't honor the value of the "port" parameter I set in /etc/asterisk/sip.conf ([general] section). I set it to 5061 (because 5060 has been used by sipxproxy).

The "Contact" header generated by CVS version of asterisk is: Contact: <sip:12345678@90.0.0.15>

By the 1.0.9 version, it is: Contact: <sip:12345678@90.0.0.15:5061>                                                                  

------------------------------------------------------------------                                    

  -- Executing SetVar("IAX2/raka_iax@raka_iax-2", "_URI_OPTIONS=play=http%3A%2F%2F90.0.0.70%3A8080%2FTracker%2Fvxml%2Ftracker.vxml%3Fp%3D1") in new stack
Aug 26 12:53:25 WARNING[22042]: pbx.c:5689 pbx_builtin_setvar_old: SetVar is deprecated, please use Set instead.
   -- Executing Dial("IAX2/raka_iax@raka_iax-2", "SIP/100@90.0.0.15:5100|999999999999|t") in new stack
We're at 90.0.0.15 port 13716
Answering/Requesting with root capability 0x2 (gsm)
Answering with capability 0x4 (ulaw)
Answering with capability 0x8 (alaw)
Answering with non-codec capability 0x1 (telephone-event)
12 headers, 12 lines
Reliably Transmitting (no NAT) to 90.0.0.15:5100:
INVITE sip:100@90.0.0.15:5100;play=http%3A%2F%2F90.0.0.70%3A8080%2FTracker%2Fvxml%2Ftracker.vxml%3Fp%3D1 SIP/2.0
Via: SIP/2.0/UDP 90.0.0.15:5060;branch=z9hG4bK28fe94bd
From: "raka_iax" <sip:12345678@90.0.0.15>;tag=as2f647f3a
To: <sip:100@90.0.0.15:5100;play=http%3A%2F%2F90.0.0.70%3A8080%2FTracker%2Fvxml%2Ftracker.vxml%3Fp%3D1>
Contact: <sip:12345678@90.0.0.15>
Call-ID: 0beeb45d540ec29d73741fd82737ea28@90.0.0.15
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Fri, 26 Aug 2005 17:53:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: 257

v=0
o=root 22042 22042 IN IP4 90.0.0.15
s=session
c=IN IP4 90.0.0.15
t=0 0
m=audio 13716 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -

---
Aug 26 12:53:26 WARNING[22042]: chan_sip.c:960 __sip_xmit: sip_xmit of 0x8441fa8 (len 870) to 90.0.0.15 returned -1: Bad file descriptor
   -- Called 100@90.0.0.15:5100
Retransmitting #1 (no NAT) to 90.0.0.15:5100:
INVITE sip:100@90.0.0.15:5100;play=http%3A%2F%2F90.0.0.70%3A8080%2FTracker%2Fvxml%2Ftracker.vxml%3Fp%3D1 SIP/2.0
Via: SIP/2.0/UDP 90.0.0.15:5060;branch=z9hG4bK28fe94bd
From: "raka_iax" <sip:12345678@90.0.0.15>;tag=as2f647f3a
To: <sip:100@90.0.0.15:5100;play=http%3A%2F%2F90.0.0.70%3A8080%2FTracker%2Fvxml%2Ftracker.vxml%3Fp%3D1>
Contact: <sip:12345678@90.0.0.15>
Call-ID: 0beeb45d540ec29d73741fd82737ea28@90.0.0.15
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Date: Fri, 26 Aug 2005 17:53:26 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Content-Type: application/sdp
Content-Length: 257

v=0
o=root 22042 22042 IN IP4 90.0.0.15
s=session
c=IN IP4 90.0.0.15
t=0 0
m=audio 13716 RTP/AVP 3 0 8 101
a=rtpmap:3 GSM/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
By: Olle Johansson (oej) 2005-08-27 15:42:38

Read sip.conf.sample

I am closing this, since we have another solution to the problem. Thanks for testing!