On Mon, Jun 23, 2008 at 8:15 PM, Pedro Gon?alves <pedro.pandre at gmail.com> wrote: > > I think the documentation doesn't explain *how to* do the subsequent offer / > answer, and so I will tell what I've done so far: > I think the rest is probably explained in the invite session's offer answer framework in the Dev Guide PDF. But okay here it goes. When sending subsequent offer, once you have the local SDP (either getting the active SDP from SDP negotiator in the invite session, or creating a fresh one from pjmedia_endpt), once again you'd need to call pjmedia_transport_encode_sdp() to let it put transport information in the offer. Then you'd send the SDP with pjsip_inv_update() or pjsip_inv_reinvite(). When you receive subsequent incoming offer, the on_rx_offer() callback of the invite session is called. Again you'd create the local SDP and give it to pjmedia_transport_encode_sdp() along with the remote offer. Then give the SDP to pjsip_inv_set_sdp_answer() to be sent to the response (of the re-INVITE or UPDATE). To make it complete, you'd need to implement another callback, on_create_offer(), of the invite session. This callback is called when you receive re-INVITE without SDP. > Let's make things clear with the new API: A wants to call B, so: > -In order to create the initial offer, A calls *pjmedia_ice_create*, > *pjmedia_transport_media_create* and *pjmedia_transport_encode_sdp* > -The offer goes to B (INVITE is sent to B) > -B receives A's offer (INVITE), calling also *pjmedia_ice_create*, > *pjmedia_transport_media_create* and *pjmedia_transport_encode_sdp*. All good so far. > -B calls *pjmedia_transport_media_start* in order to start ICE connectivity > checks > -B sends the answer to A (in a 200 OK INVITE) > No that's incorrect. What you should do is: - send the SDP to the 200/OK response. - the on_media_update() then is called, and in the callback you'd get both the active local SDP and active remote SDP, and then give it to pjmedia_transport_media_start(). > OK, this is what I've acomplished so far. > > However, I've been unable to advance further, as I am unable to > > 1) make A call pjmedia_transport_media_start* in order to start ICE > connectivity checks; > 2) after A's connectivity checks are done, send the subsequent offer; > > althought I have a method in my application to war me about INVITE state > changes: > *OnCallStateChanged(pjsip_inv_session *inv, pjsip_event *e)* > I am debugging it order to stop when > *inv->state == PJSIP_INV_STATE_CONNECTING*, > which claims to be the state when /**< After 2xx is sent/received. */ > > However, if I analise the pjsip_inv_session *inv variable, I can see that it > has the variable "pjmedia_sdp_neg *neg". However, although this variable > holds all theses SDPs: > pjmedia_sdp_session *initial_sdp, /**< Initial local SDP > */ > *active_local_sdp, /**< Currently active local SDP. */ > *active_remote_sdp, /**< Currently active remote's. */ > *neg_local_sdp, /**< Temporary local SDP. */ > *neg_remote_sdp; /**< Temporary remote SDP. */ > only initial_sdp is not null, all the other ones are! > I can't undersand why, because if we have already received the 200 OK INVITE > we should have both local and remote sdp offers, shouldn't we? > This way, I don't know the local and remote sdps, and so I can't start A's > ICE connectivty checks (call pjmedia_transport_media_start). > (BTW, I think I found a tricky way to get the remote SDP: > pjsip_rx_data *rd_data = e->body.tsx_state.src.rdata; > pjmedia_sdp_session *remote_sdp =(pjmedia_sdp_session*) > rd_data->msg_info.msg->body->data; > Is this correct?) > I suspect probably you didn't put the SDP in the 200/OK answer? In A, the on_media_update() callback is called as soon as it receives SDP from B (which can be in 200 or 183 response). A then can get both active local and active remote SDP and then call pjmedia_transport_media_start(), exactly the same as in B. > Another question: what is the SIP message flow in this case? As I said, the > intial offer is an INVITE and the initial answer is a 200 OK INVITE. Will an > ACK be sent? Will another INVITE (subsequent offer) / 200 OK INVITE > (subsequent answer) / ACK be exchanged? > Yes ACK will be sent automatically by default, and no there won't be no subsequent offer automatically sent by the stack. You'd have to manually initiate it if you want to. Cheers Benny > Thanks for the help > Pedro Gon?alves > > _______________________________________________ > 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 > >
