[asterisk-bugs] [Asterisk 0012902]: Video RTP is not sended to originating SIP extension when using IAX2 to interconnect both servers
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Feb 17 09:51:16 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12902
======================================================================
Reported By: albersag
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 12902
Category: Channels/chan_iax2
Reproducibility: always
Severity: major
Priority: normal
Status: confirmed
Asterisk Version: 1.4.18
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2008-06-20 02:46 CDT
Last Modified: 2009-02-17 09:51 CST
======================================================================
Summary: Video RTP is not sended to originating SIP extension
when using IAX2 to interconnect both servers
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.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0008824 [patch] Remote (called) Party Identific...
======================================================================
----------------------------------------------------------------------
(0100246) stevedavies (reporter) - 2009-02-17 09:51
http://bugs.digium.com/view.php?id=12902#c100246
----------------------------------------------------------------------
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 at 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 at 192.168.100.23>;tag=as4e729055
To: <sip:5000 at 192.168.100.25:5060>
Contact: <sip:4000 at 192.168.100.23>
Call-ID: 503ec0d54f2c13d956848b690c12d0bf at 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 at 192.168.100.23
CSeq: 102 INVITE
Contact: <sip:5000 at 192.168.100.25:5060>
From: "Tandberg 01" <sip:4000 at 192.168.100.23>;tag=as4e729055
To: <sip:5000 at 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
Issue History
Date Modified Username Field Change
======================================================================
2009-02-17 09:51 stevedavies Note Added: 0100246
======================================================================
More information about the asterisk-bugs
mailing list