Hi Anshuaman. I have the same problem of loss audio. If you found a solution please contact me. I'll do the same for you. Thanks ---------------------------------------- > From: arawat@xxxxxxxxxxx > To: pjsip at lists.pjsip.org > Date: Wed, 21 Nov 2007 17:21:06 +0530 > Subject: Re: 3PCC transfer implementation > > Hi Benny, > > Joegen mentions - > "In addition to the dangers of 3PCC call transfer is that some user agents > ignore RTP packets whose ssrc has changed. I have seen implementation > that throws away rtp packets with different ssrc than what it was previous > receiving." > > Is this an issue with pjsip? We are testing 3PCC transfer and have noticed > that the transferee cannot hear anything but can be heard by the party it > was transferred to. Putting more clearly - > > - A calls B > - B transfers A to C > > C can hear A but A cannot hear C. For traces, we can see that signalling is > fine and bi-directional RTP flows between A & C. > > Regards, > Anshuman > > > ----- Original Message ----- > From: "Joegen E. Baclor" > To: "pjsip embedded/DSP SIP discussion" > Sent: Wednesday, November 14, 2007 5:21 PM > Subject: Re: 3PCC transfer implementation > > >> Benny Prijono wrote: >>> Joegen E. Baclor wrote: >>> >>>> Benny Prijono wrote: >>>> >>>>> Hi Anshuman, >>>>> >>>>> this is currently pretty hard to achieve with pjsip, as ACK will be >>>>> sent automatically by the invite session layer upon receiving 2xx >>>>> response. But I like your idea to add the ability to disable this >>>>> automatic ACK sending and enabling application to send it manually, >>>>> so maybe we can elaborate more on this. Can you explain more on why >>>>> did you think this approach is not very extensible? >>>>> >>>>> >>>> Although it is most definitely a good idea to have ACK for 200 OK be >>>> handled by the application layer, I do not see its significance in a >>>> B2BUA as mentioned in the original post. It will only be significant if >>>> the implementation is a Proxy. In which case, ACK needs to be processed >>>> hop by hop to assure that every entity in the call path know that the >>>> ultimate endpoint has received the 200 Ok. It would be interesting >>>> to know if there are other reasons. >>>> >>> >>> Hi Joegen, >>> >>> thanks for jumping in the discussion. I'm sure you have much much >>> more experience with B2BUA than most of us, so your inputs on this >>> would be great! >>> >>> Regarding 3PCC, I was thinking of the scenarios in 3PCC best >>> practices RFC (http://www.ietf.org/rfc/rfc3725.txt), and I see that >>> in these scenarios we always need to delay the ACK until we have the >>> answer from the other side. I was assuming that although it's a >>> B2BUA, we want the RTP to flow end to end (i.e. the controller >>> doesn't want to proxy the RTP). >>> >> Ooops, yeah i've missed that as a valid reason why the app layer needs a >> handle on the ACK. However, for a 3PCC call transfer where the offer >> is already known based on the previously established session, there is >> no need to send a blank invite in this case. The 3PCC app may just send >> the active SDP in whichever leg is being transfered. Once a new codec >> is negotiated from the 200 OK, the 3pcc layer can just send a reinvite >> to the transferred call to notify it about the new codec, address and >> port chosen by the new leg. Although, this approach is somehow >> dangerous since the reInvited UA may decide to change the port in the >> answer different to what was previously offered. I yet have to see a >> UA that behaves this way but since it's not controlled by any specs, we >> can't really complain if one person decided to do it that way. In >> addition to the dangers of 3PCC call transfer is that some user agents >> ignore RTP packets whose ssrc has changed. I have seen implementation >> that throws away rtp packets with different ssrc than what it was >> previous receiving. This justifies proxying media for such cases since >> the media proxy can always send the same ssrc to a particular leg even >> if the source of the packet has already changed. >>> Or do you have other 3PCC scenarios in mind that doesn't require >>> delaying ACK? >>> >> >> In fact there is. One can send an INVITE with a held media which is >> case II (just pulled it from mem) as i remember it from the specs. >> There are a lot of implementation that do not support late media (blank >> invites). One good reason why we may consider staying away from case >> I. In a perfect world, however, case I is best practice in my opinion >> and will produce the most desired results. I guess that leaves you no >> choice but the expose ACK to the application layer ;-) >> >>> thanks, >>> -benny >>> >>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip at lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >>> >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.503 / Virus Database: 269.15.31/1129 - Release Date: >> 11/13/2007 9:22 PM >> >> > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org _________________________________________________________________ D?couvrez Windows Live Spaces et cr?ez votre site Web perso en quelques clics ! http://spaces.live.com/signup.aspx
