ICE Clarification

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

Congratulations on the new release!

I've updated to the latest version but, however, still need some 
clarifications on the ICE processing.

As far as I can understand, this is the ICE process flow:
1) Caller sends Initial Offer by calling *pjmedia_ice_create*, 
*pjmedia_transport_media_create* and *pjmedia_transport_encode_sdp*
2) Callee receives the Initial Offer and sends the Initial Answer by 
calling the same functions: *pjmedia_ice_create*, 
*pjmedia_transport_media_create* and *pjmedia_transport_encode_sdp*
3) Callee starts ICE connectivity checks when *on_media_update()* is 
called, by calling *pjmedia_transport_media_start*
4) Caller's *on_media_update()* is called and he also starts ICE 
connectivity checks by calling *pjmedia_transport_media_start*
5) When Caller's *on_ice_complete* is called with ice_strans_op == 
PJ_ICE_STRANS_OP_NEGOTIATION, he sends the Subsequent Offer, by calling 
*pjmedia_endpt_create_sdp*, *pjmedia_transport_encode_sdp*, 
*pjsip_inv_reinvite* and *pjsip_inv_send_msg*
6) Callee receives Subsequent Offer on *on_rx_offer()*  and sends 
Subsequent Response by calling *pjmedia_endpt_create_sdp*,  
*pjmedia_transport_encode_sdp* and *pjsip_inv_set_sdp_answer*

Is this process OK?
Although the Initial Offer, Initial Answer and Subsequent Offer seem OK 
to me (in Subsequent Offer I can see that a=remote-candidates is being 
sent),
I think that something must be wrong, since Subsequent Answer is being 
sent just like an Initial Offer



[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux