[Home]

Summary:ASTERISK-12236: Video RTP is not sended to originating SIP extension when using IAX2 to interconnect both servers
Reporter:Alberto Sagredo (albersag)Labels:
Date Opened:2008-06-20 02:46:04Date Closed:2011-06-07 14:02:37
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_iax2
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20080625__bug12902__debug__2.txt
( 1) 20080625__bug12902__debug.txt
Description:When i use IAX2 to interconnect two servers, Asterisk does not send RTP in H.263,263+ or H.264 to the originating SIP extension of the call.

It´s always reproducible and it always happens in originating extension. Other party could see you but you could not see him/her.

Analyzing RTP/SIP captures, i see Asterisk1 (from where i originate SIP Video Call) does not receive RTP packets in video códec sended by client SIP2 in other Asterisk2

It does not depend on Softhphone or Hardphone used. We had same problem with Grandstream GXV3000, or instead Eyebeam Softphone.

****** ADDITIONAL INFORMATION ******

We used 1.4.18 version of Asterisk.
Comments:By: Tilghman Lesher (tilghman) 2008-06-20 14:27:01

Interesting.  I just tried this (SIP-IAX-IAX-SIP) and it worked fine with video (on Asterisk 1.4.21).  Can you provide any more information on your setup that would help in diagnosing what the issue is?
By: Tilghman Lesher (tilghman) 2008-06-20 14:28:07

One question:  do you have videosupport=yes in sip.conf?
By: Alberto Sagredo (albersag) 2008-06-21 08:05:19

I used 1.4.18 .

Let me try in 1.4.21 on monday and let you know.

Videosupport was yes and allow video codecs con sip.conf as expected. .

Best Regards

Alberto
By: Alberto Sagredo (albersag) 2008-06-23 03:08:35

I have tried with 1.4.21 and i have the same problem.

In sip.conf

videosupport=yes

a iax peer between them,

and

disallow=all
allow=alaw
allow=ulaw
allow=h263
allow=h263+
allow=h264

What was your config?

Im using Eyebeam with video right now

Best regards
By: Wu Xing (calka) 2008-06-25 20:42:47

I met the same problem with asterisk 1.4.17 !
When I use ami command "originate" to create a call like this:
 Action: Originate
 Channel: SIP/301
 Exten: 303
 Callerid: 301
 Context: from-sip
 Priority: 1

extensions.conf:

 exten => _30X,1,Dial(SIP/${EXTEN})

301 can see the video from 303,but 303 can not see the video from 301.
If 301 dial 303 directly ,the video works fine.
By: Tilghman Lesher (tilghman) 2008-06-25 21:48:09

Interesting.  I have reproduced the problem, if I originate the call with a call file.  If I direct dial from a phone, it works perfectly.  I have uploaded two debug files with the complete sip debug and rtp debug output.  The first represents the failure of video and the second represents video working (for comparison).
By: Wu Xing (calka) 2008-06-26 02:48:02

Download the patch from issue id 0008824 .
I patched it and it killed the bug.

But when I use app_conference (a video conference module),
I "originate" a phone into the conference ,it still didn't send video.
By: ivanfepe (ivanfepe) 2008-07-09 08:28:19

I have the same problem with Asterisk 1.4.19! But I have to interconnect two SIP clients directly (SIP-SIP). I'm usign eyeBeam.

When I set h.263 (only H.263) in Client A and Client B I sent video in both ways but when I tried it using H.264 (I set h.264 in Client A and Client B and only H.264 configured) I sent video from Client A to Client B but I couldn't from client B to client A at the same time.
By: Alberto Sagredo (albersag) 2008-07-10 05:50:29

I have patched 1.4.21.1 with patch related on bug 8824.

I have same problem with a iax link between two Asterisk 1.4.21.1 with patched applied.

I have used Bria and Eyebeam and same result, No video on caller end

Anyone has made this test?

Best REgards


By: Steve Davies . (stevedavies) 2009-02-17 09:51:15.000-0600

Hi,

I've been testing two Tandberg fancy video conf units and experimenting with passing calls between the units via Asterisk.

I've also hit the reported problem when I use IAX2 between the Asterisk boxes.

Hookup as follows:

vcu1 -SIP> ast1 -IAX2> ast2 -SIP> vcu2

Asterisk version is 1.4.19 on the test units.

Video from the caller end (vcu1) makes it across the IAX2 link and is delivered to the destination and displays.

In the return direction, The called unit (vcu2) does send H263 RTP stream to ast2, however that stream does not get forwarded on the IAX2 trunk.

Nothing special gets logged on ast2.

The SIP negotiation at each end does include negotiating for h263, as can be seen by the fact that the units are both sending H263 RTP stream.

Here is the negotiation as logged on ast2 as the packets aren't forwarded:

Incoming IAX call from ast1:

[Feb 17 17:09:33] VERBOSE[8066] logger.c: Rx-Frame Retry[ No] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW    
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    Timestamp: 00002ms  SCall: 00001  DCall: 00000 [192.168.100.22:4569]
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    VERSION         : 2
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    CALLED NUMBER   : 5000
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    CODEC_PREFS     : (alaw)
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    CALLING NUMBER  : 4000
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    CALLING PRESNTN : 0
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    CALLING TYPEOFN : 0
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    CALLING TRANSIT : 0
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    CALLING NAME    : Tandberg 01
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    LANGUAGE        : en
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    FORMAT          : 524296
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    CAPABILITY      : 581640
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    ADSICPE         : 2
[Feb 17 17:09:33] VERBOSE[8066] logger.c:    DATE TIME       : 2009-02-17  17:09:32


Corresponding SIP invite to the vcu2, including the h263:

INVITE sip:5000@192.168.100.25:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.100.23:5060;branch=z9hG4bK31cb367d;rport
From: "Tandberg 01" <sip:4000@192.168.100.23>;tag=as4e729055
To: <sip:5000@192.168.100.25:5060>
Contact: <sip:4000@192.168.100.23>
Call-ID: 503ec0d54f2c13d956848b690c12d0bf@192.168.100.23
CSeq: 102 INVITE
User-Agent: Asterisk PBX
Max-Forwards: 70
Date: Tue, 17 Feb 2009 15:09:33 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 338

v=0
o=root 3395 3395 IN IP4 192.168.100.23
s=session
c=IN IP4 192.168.100.23
b=CT:512
t=0 0
m=audio 12142 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
m=video 10300 RTP/AVP 34
a=rtpmap:34 H263/90000
a=sendrecv

"OK" back from the unit:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.100.23:5060;branch=z9hG4bK31cb367d;received=192.168.100.23;rport=5060
Call-ID: 503ec0d54f2c13d956848b690c12d0bf@192.168.100.23
CSeq: 102 INVITE
Contact: <sip:5000@192.168.100.25:5060>
From: "Tandberg 01" <sip:4000@192.168.100.23>;tag=as4e729055
To: <sip:5000@192.168.100.25:5060>;tag=628c51fb0ec16d96
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,INFO,OPTIONS,REFER,NOTIFY
Server: TANDBERG/67 (F7.2 PAL)
Supported: replaces,100rel,timer,com.tandberg.sdp.extensions.v1
Session-Expires: 500; refresher=uas
Min-SE: 90
Allow-Events: tandberg-dtmf
Content-Type: application/sdp
Content-Length: 398

v=0
o=tandberg 1 2 IN IP4 192.168.100.25
s=-
c=IN IP4 192.168.100.25
b=CT:512
t=0 0
m=audio 46650 RTP/AVP 8 0 101
b=TIAS:64000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
m=video 46652 RTP/AVP 34
b=TIAS:512000
a=rtpmap:34 H263/90000
a=fmtp:34 cif4=2;cif=1;qcif=1;sqcif=1;maxbr=5120
a=sendrecv
a=content:main
a=label:11

tcpdump reveals that RTP H263 video does arrive from vcu2, but doesn't get forwarded.

I will add additional debugging to see if I can see where they go...

Regards,
Steve
By: Leif Madsen (lmadsen) 2009-05-20 09:10:01

stevedavies: did you have a chance to add the additional debugging?
By: Leif Madsen (lmadsen) 2009-07-13 10:37:17

I'm closing this for now due to lack of response. If someone can provide some additional information here, please feel free to reopen the issue. Thanks!