On Thu, Jun 12, 2008 at 2:22 PM, Sasa Coh <sasacoh at gmail.com> wrote: > 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. > Since the To-tag doesn't change, probably we can try this. Basically we will force the server to not change the SDP between 18x and 2xx response, by using reliable response. Hopefully this will make the server sends the new SDP with UPDATE or re-INVITE, which we support. You can force the server to send answer reliably either with using TCP or TLS transport, or using reliable provisional response extension with --use-100rel option (in pjsua). If the server still sends modified SDP in 2xx, at least we can then blame it for being non-compliant. ;-) Cheers Benny > 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 > > > _______________________________________________ > 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 > >
