A NOTE has been added to this issue. 
====================================================================== 
https://bugtracker.iptel.org/view.php?id=73 
====================================================================== 
Reported By:                jh
Assigned To:                
====================================================================== 
Project:                    SEMS
Issue ID:                   73
Category:                   SBC
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
====================================================================== 
Date Submitted:             2012-03-02 04:13 CET
Last Modified:              2012-03-27 12:30 CEST
====================================================================== 
Summary:                    duplicate audio section in sbc session timer
re-invites
Description: 
when sbc is using session timer, re-invites after the first one (packet 8)
contain duplicate sdp audio section (packets 11 and 12).  

also, re-invite in packet 12 to a leg uac should not have been sent so soon
as the previous one to the same uac (packet 8) was sent within the same
second.
====================================================================== 

---------------------------------------------------------------------- 
 (0000113) jh (reporter) - 2012-03-03 03:38
 https://bugtracker.iptel.org/view.php?id=73#c113 
---------------------------------------------------------------------- 
Correction:  the first re-invite that includes duplicate audio section
(packet 11) is sent by sems echo server at b leg.  i guess that explains
why following re-invites from sems sbc contain the same sdp.  so looks like
the bug is in echo server session timer.  rtp relaying is not enabled. 

---------------------------------------------------------------------- 
 (0000115) jh (reporter) - 2012-03-03 21:03
 https://bugtracker.iptel.org/view.php?id=73#c115 
---------------------------------------------------------------------- 
i uploaded debug output from sems echo server that shows the original
invite it received as well as the re-invite it sent.  original invite has
two sdp media parts: audio and video.  since sems echo plugin does not
support video, it included in 200 ok an inactive video part.  but when it
sent the session timer re-invite, this inactive video media part got
replaced by another audio media part, which causes the problem.  it should
just use the saved copy of sdp body from its 200 ok to the initial invite
if there is one somewhere. 

---------------------------------------------------------------------- 
 (0000116) jh (reporter) - 2012-03-27 12:30
 https://bugtracker.iptel.org/view.php?id=73#c116 
---------------------------------------------------------------------- 
i think i found why sdp of re-invite from sems echo server contains two
audio sections.  when sems replied to original invite that included both
audio and media sections in sdp, 200 ok had this kind of sdp:

            Media Description, name and address (m): audio 40004 RTP/AVP
100 10
3 9 8 0 104
            Media Attribute (a): rtpmap:100 speex/16000
            Media Attribute (a): fmtp:100 mode="7";vbr=off;cng=on
            Media Attribute (a): rtpmap:103 speex/8000
            Media Attribute (a): fmtp:103 mode="7";vbr=off;cng=on
            Media Attribute (a): rtpmap:9 g722/8000
            Media Attribute (a): rtpmap:8 PCMA/8000
            Media Attribute (a): rtpmap:0 PCMU/8000
            Media Attribute (a): rtpmap:104 telephone-event/8000
            Media Attribute (a): fmtp:104 0-15
            Media Attribute (a): direction:passive
            Media Attribute (a): sendrecv
            Media Description, name and address (m): video 0 RTP/AVP 96
            Media Attribute (a): inactive

when sems then sends out session timer re-invite, it calls
AmSession::getSdpOffer with an offer that has two media sections:

Mar 27 13:14:47 node1 sems[12654]: [#b54eab70] [getSdpOffer,
AmSession.cpp:970] INFO: Before offer media (port 40000, payloads: 100 103
9 8 0 104)
Mar 27 13:14:47 node1 sems[12654]: [#b54eab70] [getSdpOffer,
AmSession.cpp:970] INFO: Before offer media (port 0, payloads: 96)

then AmSession::getSdpOffer makes this kind of call:

    RTPStream()->getSdpOffer(RTPStream()->getSdpMediaIndex(),
                             offer.media.back());

and after that the offer looks wrongly like this:

Mar 27 13:14:48 node1 sems[12654]: [#b54eab70] [getSdpOffer,
AmSession.cpp:983] INFO: After offer media (port 40000, payloads: 100 103 9
8 0 104)
Mar 27 13:14:48 node1 sems[12654]: [#b54eab70] [getSdpOffer,
AmSession.cpp:983] INFO: After offer media (port 40000, payloads: 101 102 8
0 3 2 9 96 97 98 99 100)

questionss:  why is the last (= second) media section corresponding to the
unsupported video stream passed to RTPStream()->getSdpOffer and why is it
replaced by port 40000, payloads: 101 102 8 0 3 2 9 96 97 98 99 100?  why
is AmRtpAudio::getSdpOffer overwriting offer type to audio:

void AmRtpAudio::getSdpOffer(unsigned int index, SdpMedia& offer)
{
  offer.type = MT_AUDIO;
  INFO("Getting sdp offer for index %u, offer '%s'\n",
       index, offer.debugPrint().c_str());
  AmRtpStream::getSdpOffer(index,offer);
}

-- juha 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2012-03-02 04:13 jh             New Issue                                    
2012-03-02 04:13 jh             File Added: timer.pcap                       
2012-03-03 03:38 jh             Note Added: 0000113                          
2012-03-03 03:39 jh             Note Added: 0000114                          
2012-03-03 03:43 jh             Note Deleted: 0000114                        
2012-03-03 20:55 jh             File Added: echo.debug                       
2012-03-03 21:03 jh             Note Added: 0000115                          
2012-03-27 12:30 jh             Note Added: 0000116                          
======================================================================
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev

Reply via email to