Hi, Thanks Benny, I got it. Well, we have no To-tag change and unreliable transport. Is there any other SIP scenario/call flow (supported by pjsip) that would handle such functionality? Scenario again: The client receives (after 18x) tones or announcements from media server and when other party answers (2xx) the SDP is changed. thanks again, sasa On Thu, Jun 12, 2008 at 2:52 PM, Benny Prijono <bennylp at pjsip.org> wrote: > On Thu, Jun 12, 2008 at 11:59 AM, Sasa Coh <sasacoh at gmail.com> wrote: > > Hello Benny! > > > > I have question regarding SDP negotiation process. We managed to > establish > > signaling connection with the other party but there was no (correct) > voice > > path established. > > > > Here is how it goes: > > - pjsua makes call through Call Agent: INVITE with SDP (offer). > > - Call Agent responds with 180 Ringing with SDP (answer). Here SDP > points > > to the Media Server that provides "Ring Back" tone to the caller. > > - When called party accepts the call, Call Agent sends 200 OK with yet > > another SDP (offer/answer?) points to the called party. > > - After that there is no voice path? to be exact, voice path is still > > established to the media server providing tones but not to the called > party > > as directed in the latter SDP. > > > > The same situation works with other clients (X-Lite). > > > > Does pjsip support this kind of SDP negotiation? Should we handle some > > callback we are not aware of? > > > > I think this is quite a complicated scenario, and which one it is > depends on whether the server changes the To tag between 18x and 2xx > response. If it does change, then this is a similar scenario to > forking with early media, which we don't handle at PJSUA-LIB level (we > do have basic forking handler at PJSIP level, but I don't implement > forking at PJSUA-LIB level due to complexities in handling the media). > > If the To-tag doesn't change, then it further depends on whether the > SIP transport is reliable or not. If the transport is not reliable, it > means server is sending "provisional" SDP in 18x response and the > "final" SDP in the 2xx response which the UAC should use. This, albeit > hairy is a valid SIP scenario. But we don't seem to handle this > either. If the transport is reliable, then the SDP in 18x is the final > one and UAC must ignore the SDP in 2xx since it belongs to the same > transaction, and if this is the case, PJSIP is doing the right thing. > > So there you go. :) > > Cheers > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080612/dfae7f45/attachment-0001.html
