Fwd: [Serusers] mediaproxy module: RTP packet mapping after reINVITE with new SDP

[Joel Rosenfield]

Anyone have a comment on the problem that I observe in which the mediaproxy
receives a request for a session with a media description that has a new
(rather than additional) connection address, but does not act upon it?  Is
there continuing work going on for this module?

Here is my latest code which seems to solve the problem of a simple
1-audio-session call, while attempting to preserve the existing video add-on
capability.  Please excuse the clumsiness of the code as I am new to python. 
While it doesn't solve the general SDP management case, it does solve the
simple and most common case of 1 audio stream.  If the project leadership
thinks this is useful, I can come up with a more complete solution and submit
the code.  However, if there is already ongoing work in this area, I don't want
to duplicate the effort.

Thanks,
- Joel 

    # class RTPSession
    def updateStreams(self, sessionData):
        print "updateStreams"
        streams = [s.split(':') for s in sessionData[2].split(',')]
        streamCount = len(self.mediaStreams)
        if streamCount < len(streams):
            # Add one media session.
            print "Adding Streams"
            visibleIP = sessionData[3]
            asymmetric = self.callerInfo.get('asymmetric', 0)
            for sinfo in streams[streamCount:]:
                try:
                    mediatype = sinfo[2]
                except IndexError:
                    mediatype = 'Audio'
                    # remove at a later time
                    print("warning: SER is using an old mediaproxy.so module. "
                          "Please upgrade it to get correct media type
information.")
                try:
                    stream = MediaStream(self, mediatype)
                except MediaStreamError:
                    # check this. also at session creation
                    #for stream in self.mediaStreams:
                        #stream.close()
                    raise RTPSessionError, "cannot find enough free ports for
the media streams"
                stream.setCaller(sinfo, visibleIP, asymmetric)
                self.mediaStreams.append(stream)
            self.oldCount = streamCount
            self.needStreamUpdate = 1

        sinfo = streams[0]
        print "updateStreams checking for same media"
            # if sinfo[0] ==
self.mediaStreams[0].rtpStream.caller.__v.contactIP
            #     if sinfo[1] ==
self.mediaStreams[0]rtpStream.caller.__v.rtpPort
            #         # No change to media
            #         return
            # Media changed.
        print "Media IP:port is %s:%s" % (sinfo[0], sinfo[1])
        visibleIP = sessionData[3]
        asymmetric = self.callerInfo.get('asymmetric', 0)
        self.mediaStreams[0].rtpStream.caller = None
        self.mediaStreams[0].setCaller(sinfo, visibleIP, asymmetric)
        print "updateStreams returning"

 



--- Joel Rosenfield <joelrosenfield at yahoo.com> wrote:

> Date: Tue, 15 Nov 2005 08:31:00 -0800 (PST)
> From: Joel Rosenfield <joelrosenfield at yahoo.com>
> To: serusers at lists.iptel.org
> Subject: [Serusers] mediaproxy module: RTP packet mapping after reINVITE
> 	with new SDP
> 
> As I am new to this list, please tell me if there is a more appropriate list
> to
> which I should post this question.
> 
> Does the mediaproxy handle changes in the media description within the same
> call dialog?  If not, are there plans to do so?
> 
> 
> Here is what I have done:
> 
> I am using the SER mediaproxy module v1.4.2 and a co-located proxydispatcher
> and mediaproxy to accomplish NAT traversal between a 3PCC and an remote ATA. 
> All basic call scenarios work fine.  However, when the module receives a
> reINVITE to reconnect the ATA to a different party, the mediaserver fails to
> forward the RTP packets between the ATA and party described in the new SDP.
> 
> I saw in the mediaproxy logs that RTP packets had been received from both
> sides, but the signIn method was being invoked as "called" for both parties.
> 
> I explored the rtphandler.py and saw that the "catchall" clause at the end of
> RTPStream.handle_read was being invoked as you can see by the debug statement
> that I added to the code.  It appears that this is invoked because both
> parties
> had already signed in based upon the previous media description, so none of
> the
> other mapping/forwarding clauses are invoked.
> 
> It seems that there needs to be a mechanism to clear the mappings when the
> mediaproxy receives a "request" command for the same session (based upon the
> SIP Call-ID) but a new SDP.  I got it work by adding code to the beginning of
> RTPSession.updateStreams() that clears the list "mediaStreams" and letting
> the
> rest of the code in that method recreate the mappings from scratch.  See the
> attached file containing the code, a mediaproxy log before the change, and a
> log from after the change.
> 
> Although this works, the solution is a bit incomplete since it can cause
> brief
> interruptions in the RTP stream when a reINVITE is received that does not
> include an SDP change, etc.
> 
> Please let me know if there is something I am missing with respect to how I
> should using the mediaproxy.  
> 
> Thanks,
> - Joel Rosenfield
> 
> 
> 		
> __________________________________ 
> Yahoo! FareChase: Search multiple travel sites in one click.
> http://farechase.yahoo.com> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 



		
__________________________________ 
Start your day with Yahoo! - Make it your home page! 
http://www.yahoo.com/r/hs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mediaproxyissue.log
Type: application/octet-stream
Size: 7356 bytes
Desc: pat1398239590
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20051118/8bf0cddc/attachment.obj>
-------------- next part --------------
_______________________________________________
Serusers mailing list
serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers