Hello,
I have some new informations.
My SDP negociations failed because of the following reason :
pjmedia_sdp_transport_cmp(&answer->desc.transport, &offer->desc.transport)
doesn't return PJ_SUCCESS.
When I check the corresponding values of the parameters, I have :
&answer->desc.transport = { 0x8117f14 "ESP_TRANSPORT/UDP\r\na=crypto:1",
slen=29 }
&offer->desc.transport = { 0x8113d94 "ESP_TRANSPORT/UDP", slen=17 }
It doesn't seems to parse correctly my answer, but I can find a workaround.
Did someone has any ideas ?
On Wed, Nov 19, 2008 at 3:11 PM, pierrick grasland <
pierrick.grasland at nexcom.fr> wrote:
> Hi,
>
> I have encounter a new problem with sdp negociation.
>
> Like I said before, my code is based on simpleua.c, and I'm trying to have
> the following call flow :
>
> UAC -------Invite (a)--------->B2BUA---------Invite (b)--------->UAS
> UAC <------------------------200 ok
> (c)-----------------------------------UAS
> UAC
> ----------------------------ACK----------------------------------------->UAS
>
>
> UAC
> -------------------------------BYE-------------------------------------->UAS
> UAC <------------------------200 ok
> ---------------------------------------UAS
> UAC
> ----------------------------ACK---------------------------------------->UAS
>
>
> where :
>
> INVITE (a) contain a sdp with the following media in SDP (only this one)
>
> m=application 0 ESP_TRANSPORT/UDP
> a=crypto:1 ESP_AES_CBC_128_HMAC_MD5_96 inline:|any|192.168.209.20:
> |24500::|::
>
> This part is ok, I can send this sdp
>
> INVITE (b) is updated by my B2BUA :
>
> m=application 0 ESP_TRANSPORT/UDP
> a=crypto:1 ESP_AES_CBC_128_HMAC_MD5_96
> inline:4avswQmkSryflkF851qRPg==|any|192.168.209.20:|24500:sec:3600|:sec:3600
> (in one line)
>
> and my UAS respond to this message with the following SDP in 200 ok :
>
> m=application 0 ESP_TRANSPORT/UDP
> a=crypto:1 ESP_AES_CBC_128_HMAC_MD5_96
> inline:4avswQmkSryflkF851qRPg==|any|192.168.209.20:192.168.209.21|24500:sec:3600|24500:sec:3600
> (in one line)
>
> So, now, I have what I want in my SDP in both the request and the answer.
>
> But, when I'm checking pjsip logs, I encounter the following message :
>
>
> simpleua.c Call state changed to CONNECTING
> inv0x811277c Got SDP answer in Response msg 200/INVITE/cseq=4056
> (rdata0x80ebdc4)
> inv0x811277c SDP negotiation done, status=220046
> simpleua.c SDP negotiation has failed: SDP media transport type mismatch
> in offer/answer (PJMEDIA_SDPNEG_EINVANSTP) [code=220046]
>
> The last line is logged during on_media_update (it's the first operation,
> when we check the status). And, when I'm watching with a debugger the value
> of neg in my invite session, I can observe the following values :
>
> - state : PJMEDIA_SDP_NEG_STATE_DONE
> - has_remote_answer : 0
> - answer_was_remote : 1 (I don't understand why it's not 1 and 1 for these
> ones)
> - initial_sdp : 0x8112f4c (valid address, which contain, logically, the sdp
> of INVITE (a))
> - active_local_sdp : 0x0
> - active_remote_sdp : 0x0
> - neg_local_sdp : 0x0
> - neg_remote_sdp : 0x0
>
> So, my sdp negociation failed, but I can't understand why (same media, same
> attribute. Only inline value has changes), and where can I do a workaround
> to evade this problem ?
>
> I try to add a callback on_rx_response, but this one doesn't fire before
> on_media_update.
>
> Can someone help me on this problem ?
>
> Regards,
>
>
> On Tue, Nov 18, 2008 at 11:09 AM, Pierrick Grasland <
> pierrick.grasland at gmail.com> wrote:
>
>> Hi,
>>
>> Thanks for your help, but I prefered to only modify SDP on rx_request
>> callback.
>>
>> So, because I'm only working with one media, and I'm sure of
>> negociation value, I recreate a new sdp negociator in simpleua.c. I
>> use pjmedia_sdp_neg_create_w_remote_offer and replace remote sdp with
>> my new local sdp value. This negociator replace g_inv->negociator.
>>
>> After that, I used simpleua mechanism to negociate a valid answer
>> between local_sdp and local_sdp (param of pjsip_inv_answer, for 200
>> ok).
>>
>> Regards,
>>
>> On Mon, Nov 17, 2008 at 6:04 PM, Nanang Izzuddin <nanang at pjsip.org>
>> wrote:
>> > Hi,
>> >
>> > I think you should modify the SDP after SDP negotiated in the
>> > pjsip_inv_answer(), since the SDP negotiator may rearrange the SDP
>> > answer regarding RFC 3264 Section 6:
>> > For each "m=" line in the offer, there MUST be a corresponding "m="
>> > line in the answer. The answer MUST contain exactly the same number
>> > of "m=" lines as the offer.
>> > For example, you can modify the SDP in
>> > pjsip_inv_callback.on_media_update (call_on_media_update() in
>> > simpleua.c). Please notice about corresponding 'm=' line, so instead
>> > of resetting media_count to zero and reassign it, I guess it is better
>> > to iterate the media in the local_sdp to find the m=application line
>> > and modify it there, except you are sure there will be only one media.
>> >
>> > Regards,
>> > nanang
>> >
>> >
>> > On Mon, Nov 17, 2008 at 10:02 PM, pierrick grasland
>> > <pierrick.grasland at nexcom.fr> wrote:
>> >> Hello all,
>> >>
>> >> I'm currently working with pjsip, in order to exchange information with
>> >> m=application SDP header.
>> >>
>> >> Actually, what I need is to do the following :
>> >>
>> >> receive SDP offer with :
>> >>
>> >> m=application \r\n a=crypto:values (easily done with pjsua.)
>> >>
>> >> Generate a new sdp media, with updated value (media2):
>> >>
>> >> something like that : m=application \r\n a=crypto:updated_values
>> (done)
>> >>
>> >> I add this new media in my current sdp, and try to respond to my INVITE
>> (I'm
>> >> starting from simpleua.c,).
>> >>
>> >> status = pjmedia_endpt_create_sdp( g_med_endpt,
>> rdata->tp_info.pool, 1,
>> >> &g_med_tpinfo.sock_info,
>> >> &local_sdp);
>> >> PJ_ASSERT_RETURN(status == PJ_SUCCESS, PJ_TRUE);
>> >> /* removing all sdp value */
>> >> local_sdp->media_count = 0;
>> >> /* updating local_sdp */
>> >> local_sdp->media_count ++; /* increment media count */
>> >> local_sdp->media[local_sdp->media_count - 1] = media2; /* store
>> media in
>> >> sdp's array of media */
>> >>
>> >>
>> >> I'm only interested in exchanging media2, so all other medias has been
>> >> deleted.
>> >> Then, I'm using simple_ua to send my 200 OK :
>> >>
>> >> /*
>> >> * Create invite session, and pass the UAS dialog
>> >> */
>> >> status = pjsip_inv_create_uas( dlg, rdata, local_sdp, 0, &g_inv);
>> >> PJ_ASSERT_RETURN(status == PJ_SUCCESS, PJ_TRUE);
>> >>
>> >> /*
>> >> * Now create 180 response.
>> >> */
>> >> status = pjsip_inv_initial_answer(g_inv, rdata,
>> >> 180,
>> >> NULL, NULL, &tdata);
>> >> PJ_ASSERT_RETURN(status == PJ_SUCCESS, PJ_TRUE);
>> >>
>> >> /* Send the 180 response. */
>> >> status = pjsip_inv_send_msg(g_inv, tdata);
>> >> PJ_ASSERT_RETURN(status == PJ_SUCCESS, PJ_TRUE);
>> >>
>> >> /*
>> >> * Now create 200 response.
>> >> */
>> >> status = pjsip_inv_answer( g_inv,
>> >> 200, NULL, /* st_code and st_text */
>> >> NULL, /* SDP specified now, in order to solve
>> >> local/remote confusion */
>> >> &tdata);
>> >> PJ_ASSERT_RETURN(status == PJ_SUCCESS, PJ_TRUE);
>> >>
>> >> /*
>> >> * Send the 200 response.
>> >> */
>> >> status = pjsip_inv_send_msg(g_inv, tdata);
>> >> PJ_ASSERT_RETURN(status == PJ_SUCCESS, PJ_TRUE);
>> >>
>> >>
>> >> return PJ_TRUE;
>> >>
>> >> But, now, I have a problem :
>> >>
>> >> the body of my 200 OK contain the following media :
>> >>
>> >> m=application \r\n a=crypto:values
>> >>
>> >> instead of m=application \r\n a=crypto:updated_values
>> >>
>> >> After several search in PJLIB documentation, I found pj_bool_t
>> >> prefer_remote_codec_order;
>> >> Initialized at true, it first seem to be the origin of my problem. But
>> after
>> >> some trials, it doesn't have any effect on my response.
>> >>
>> >> I don't want to modify PJLIB, for future upgrade. Can someone help me,
>> and
>> >> show me some documentation on how to create our sdp ?
>> >>
>> >> Thanks for your help.
>> >> --
>> >> Pierrick Grasland
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>>
>>
>>
>> --
>> Pierrick Grasland
>>
>
>
>
> --
> Pierrick Grasland
>
>
--
Pierrick Grasland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20081119/22e32fed/attachment.html>
