Hairpin calls support

Hello everyone,

Does asterisk supports outbound hairpin calls i.e. asterisk in audio path ( for dtmf detection ) but not in video path?

Is this kind of case possible in asterisk?

Please let me know if more details are required.

That looks like a Support question, not a General one.

I wouldn’t use “hairpin” to describe this usage.

Assuming SIP.

Up to 1.6.1, at least, Asterisk is not able to invoke direct media on one stream, but not the other. I don’t know if the situation has changed, but I would suggest it might be a fragile area of the code, if it has.

Hi David,

Thanks for replying and I am extremely sorry for posting in the wrong forum.

Actual scenario is a bit more complex where audio hairpin is only required.

Yes it is SIP.

The complete scenario is as follows.

a) Caller calls and connects to asterisk.
b) Caller presses some key to connect to 3rd party say *1.
c) Asterisk does outbound call [ Asterisk audio SDP + Video SDP from (a) ] and connects to 3rd party.
d) Does Re-Invite to caller sending ( Asterisk Audio SDP + Video SDP received in © ]

[I hope it’s not confusing ]

So, video media flows end to end i.e. caller to 3rd party but asterisk remains in audio path only [ hairpin ].

Is this possible??

Please guide me

Thanks,
Rawat

Hi

by using RFC2833 the audio doesn’t need to be kept via asterisk.

Nat may be more of an issue. the only way of seeing what happens is to set this up in your lab and test it. it will vary depending on network and user agents used.

RFC 2833 sends the DTMF as a special “codec” type (telephony events) in the media stream. It does require the RTP to go through Asterisk.

INFO would, in principle, avoid this, but is deprecated.

Hi all,

@ ianplain

Audio is required to be in the path. Its video needs to be bypassed.

@david55

I tried the scenario, and while adding SDP ( video ) in outgoing INVITE from incoming INVITE , its saying unsupported error.

[May 16 16:11:51] DEBUG[15497] chan_sip.c: Processing media-level (video) SDP a=fmtp:96 profile-level-id=42E01f;packetization-mode=1... UNSUPPORTED. [May 16 16:11:51] DEBUG[15497] chan_sip.c: Processing media-level (video) SDP a=imageattr:96 send [x=[0-640],y=[0-480]] recv [x=[0-1680],y=[0-1050]]... UNSUPPORTED. [May 16 16:11:51] VERBOSE[15497] chan_sip.c: Found video description format H264 for ID 99 [May 16 16:11:51] DEBUG[15497] chan_sip.c: Processing media-level (video) SDP a=rtpmap:99 H264/90000... OK. [May 16 16:11:51] DEBUG[15497] chan_sip.c: Processing media-level (video) SDP a=fmtp:99 profile-level-id=42E01f... UNSUPPORTED. [May 16 16:11:51] DEBUG[15497] chan_sip.c: Processing media-level (video) SDP a=imageattr:99 send [x=[0-640],y=[0-480]] recv [x=[0-1680],y=[0-1050]]... UNSUPPORTED. [May 16 16:11:51] VERBOSE[15497] chan_sip.c: Found video description format H263-1998 for ID 97 [May 16 16:11:51] DEBUG[15497] chan_sip.c: Processing media-level (video) SDP a=rtpmap:97 H263-1998/90000... OK. [May 16 16:11:51] DEBUG[15497] chan_sip.c: Processing media-level (video) SDP a=fmtp:97 CIF=1;QCIF=1;CUSTOM=1680,1050,2;VGA=2... UNSUPPORTED.

Because of that 3rd party is just sending audio sdp in 200 OK.

Note: Call is getting connected successfully but video is not flowing.

On searching , found that media attribute fmtp, imageattr is not supported. Is this intentionally done?

Can it be resolved?

Thanks,
Rawat