[Home]

Summary:ASTERISK-14510: [patch] SIP_BODY function to get a body part of a SIP message
Reporter:khw (khw)Labels:
Date Opened:2009-07-22 05:10:08Date Closed:2017-12-13 14:12:38.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Functions/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) chan_sip_func_body6.patch
( 1) chan_sip_func_body7.patch
Description:this patch adds the function SIP_BODY for chan_sip to get a body part by its Content-Type. Therefore, the existing find_sdp() is generalized to find_content() and find_sdp() calls find_content() with the parameter "application/sdp".

usage example: ${SIP_BODY(application/pidf+xml)} to get a PIDF document from the SIP body.
Comments:By: Olle Johansson (oej) 2009-09-03 14:43:35

The only reliable packet to get information out of within the dialplan is the latest INVITE message, where there's only a SDP body.

We can't possibly support getting information from any message sent during a call, since there's no dialplan execution and no events, you will likely miss whatever you want to grab. If you want to control SIP in that detail, you propably will have to do it in a SIP proxy that handles every transaction separately. Asterisk is not built that way.

I think integrating this will promise much more that we can or even want to promise.

By: klaus3000 (klaus3000) 2009-09-04 03:41:10

Hi Olle.

Of course this function can get the bodies only from the initial INVITE, as other requests do not trigger dialplan execution.

Nevertheless, the location in emergency calls is usually always in the initial INVITE - as the call routing depends already on this location.

I do not think that this will promise too much. Other functions (SIP_HEADER) also operate only on the initial requests.

This is a very usefull extension as it allows routing of emergency calls which do supply location information in call setup.

By: Olle Johansson (oej) 2009-09-04 04:07:43

You mislead me with that stuff about pidf/xml... I've never seen them in an INVITE. When you explain it like that, it might help with sip-t and related stuff as well.

By: Olle Johansson (oej) 2009-09-04 04:08:33

Oh, it wasn't you that gave that exampel, klaus3000. Nevertheless. I see the point.

By: khw (khw) 2009-09-04 04:20:13

The SIP INVITE may contain a multipart body and not only SDP. Look at the sample provided in http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01#section-5.1 which shows that SDP and location information are included in the body of a SIP INVITE. I think it could be interesting (not only for emergency calls) to use the location of the caller provided in the INVITE in the dialplan.

By: Olle Johansson (oej) 2009-09-04 04:22:43

Like SIP-t contain an extra body with SS7 ugliness, that's why I used that as an example :-)

By: Leif Madsen (lmadsen) 2009-11-20 15:39:59.000-0600

Because this functionality appears to be related to SDPs in the INVITE in particular, a discussion with John Todd and Russell Bryant has determined a better name for the function is probably SDP_BODY or SDP_DATA, or something to that effect.

By: klaus3000 (klaus3000) 2009-11-20 17:01:03.000-0600

Please not! The function is a generic to fetch any content type from body (or multipart body) - not only SDP.

In fact, probably the function is most used to fetch other content types from the body. For example we use it to get and process the PIDF-LO out of the INVITE - this is for example necessary for processing of the emergency calls (see IETF's ECRIT architecture for more details)

Thus, please do not rename it to something the function is not used for. The function is used to fetch a certain content type out of the BODY of SIP INVITEs. As the function is only useful for SIP channels, and by no means limited to SDP, I suggest to use the name SIP_BODY.

By: Olle Johansson (oej) 2009-11-21 03:32:44.000-0600

Agreed, assuming that it's SDP is wrong. There are multipart bodies as well, like in SIP-t.

By: khw (khw) 2010-01-13 03:52:00.000-0600

I just uploaded an updated version of the patch (chan_sip_func_body3.patch) so that it applies to SVN revision 239425.

Could an admin please delete the other files? Thank you.

By: Olle Johansson (oej) 2010-01-13 04:06:46.000-0600

There are still some coding issues I noticed:

- No comments with //
- Don't declare variables in the middle of a code block. (int size = )
- if statements should always have brackets {} - even if it's a one-liner

The coding guidelines are included in the doc/ directory.

Using ast_verbose for notices is not good. Maybe you should use ast_log(LOG_WARNING instead

I think this is a great addition to asterisk!

By: khw (khw) 2010-01-13 06:48:32.000-0600

Thank you for looking at the patch, oej. I fixed your issues and uploaded a new file.

By: Olle Johansson (oej) 2010-01-13 06:52:30.000-0600

Thanks !

It doesn't hurt to add

"This function only works on the INVITE that starts a dialog. Body parts from other SIP messages can't be managed from the dial plan"

to the function documentation, just to be clear.

By: khw (khw) 2010-01-13 07:13:17.000-0600

Description updated, thank you for the suggestion. Please delete the old files.

By: Olle Johansson (oej) 2010-01-13 07:20:28.000-0600

I'm fine with this addition to Asterisk. Thanks for the hard work, khw!

By: Leif Madsen (lmadsen) 2010-01-13 08:55:51.000-0600

"In case more body parts with the same Content-Type are
+ availabe, just the first is returned."

Can't we add some sort of iterator or utilize this in the same way that DUNDIQUERY and DUNDIRESULT are implemented? This would give the ability to access those multiple Content-Types as that is likely going to be the first feature request once this is implemented and used :)

Here is an example of how I would imagine it being used in a loop to sort through multiple Content-Type results (same way DUNDIQUERY and DUNDIRESULT are used).

exten => start,n,Set(BODY_ID=${SIP_BODY_QUERY(application/pidf+xml)})
exten => start,n,GotoIf($[${ISNULL(${BODY_ID})}]?no_body_id,1)
exten => start,n,Set(X=1)
exten => start,n,Set(BODY_RESULT=${SIP_BODY_RESULT(${BODY_ID},${X})})
exten => start,n,While($[${EXISTS(${BODY_RESULT})}])
; do something here with data
exten => start,n,Set(X=$[${X} + 1])   ; increment counter

; get next result
exten => start,n,Set(BODY_RESULT=${SIP_BODY_RESULT(${BODY_ID},${X})})
exten => start,n,EndWhile()

; finished the loop, no more results

exten => no_body_id,1,NoOp(Content-Type not found)

By: klaus3000 (klaus3000) 2010-01-15 04:24:50.000-0600

I propose a simpler way:

SIP_BODY(contenttype[,n])

Missing index means n=0.

The function returns the n'th body with requested content type. If there isn't such body it simply returns "". Thus, no need to use a handle.

By: khw (khw) 2010-04-15 07:15:31

If just uploaded a new version. This patch now allows to get a body part as proposed by klaus3000: SIP_BODY(contenttype[,n])
In order to get the second PIDF-LO in the body, one could use:

SIP_BODY(application/pidf+xml,2)

I hope this is a useful extension.

By: Leif Madsen (lmadsen) 2010-04-15 12:51:45

OK, looks good! Just need some testing and reviewers eyes I guess, then we can move this into trunk.

By: klaus3000 (klaus3000) 2010-12-22 03:58:23.000-0600

Looks like this enhancement was forgotten. Should we put it on the reviewboard?

By: Marco Marzetti (manzo_zeti) 2011-01-04 17:25:09.000-0600

Please, put it in reviewboard!
Thank You

By: Corey Farrell (coreyfarrell) 2017-12-13 14:12:38.194-0600

As far as I can tell the patches were never posted for review and they no longer apply cleanly so I'm suspending this ticket.