On 3/17/08, Davide Marrone <unidavide at email.it> wrote:
> Hi Benny,
> first of all thanks for your reply
>
> no, the problem isn't that, the service (voip.eutelia.it and others
> italian services) doesn't send this packet, I don't know why, but it
> doesn't arrive, if I use --use-100rel when I try to make a call I get
>
> 20:18:40.527 test.c Entered in on_call_state
> 20:18:40.527 test.c Call 0 is DISCONNECTED [reason=420 (Bad Extension)]
>
> while without it the call is made correctly, anyway I don't think that
> 100rel is the problem
>
Yeah, the 420 response means remote doesn't support the extension.
> Yes, I'm really sure that the only thing to do is to intercept the
> incoming RTP traffic. I have discoverd it using xten-xlite, I have made
> a lot of tries with tcpdump & ngrep, when I make a call to an external
> phone I have saw that:
> - the SIP packet 180 ringing doesn't arrive, never
> - I receive a SIP packet: 183 Session Progress
> - xten-xlite doesn't play the local ringing tone until the change of RTP
> traffic
>
> I really made many tries and I'm sure that the only SIP packet that
> arrive when the call in on going is 183 Session Progress and "viewing"
> with ngrep the RTP packets is really clear that, at a moment when the
> traffic change, the client start to play the local ringing tone that
> simulate the remote ringing. This moment is exactly when the remote
> phone is really ringing. So I'm sure at 100% that I have to get the RTP
> traffic.
> I don't already know what changes of the traffic I have to intercept but
> first of all I have to get it.
>
Sorry now I'm a bit lost. If you said you've got 183, then why can't
you just "start the call" with the arrival of this 183 response
(rather than waiting for the 180 response). It is quite common to
receive 183 instead of 180 if you are calling a PSTN gateway, and if
you listen to the incoming audio most likely you will hear ringing
tone with the 183 response.
>
> great, but for now there is a solution to my problem?
Since you've had 183 (and I assume there is SDP in the 183), your
media has been established, and your on_call_media_state() callback
should have been called.
So now you can just poll the media statistic of the call to see if
you've received RTP packets. You can use "dq" command in pjsua to show
the call's media statistic (and trace the implementation of this
command to see how to retrieve the media statistic programmatically).
I'm not sure why your code below doesn't work though.
cheers,
-benny
> I have tried to do that:
>
> // ...
> // initialization of pjsua and registration to the server
> // ...
>
> // make the call
> status = pjsua_call_make_call(acc_id, &uri, 0, NULL, NULL, &call_id);
> if (status != PJ_SUCCESS) error_exit("Error making call", status);
>
> // the call start correctly, i receive the SIP 183 packet
> // and my remote phone rings
>
> pjsua_call *call;
> pjmedia_sock_info skinfo;
>
> call = &pjsua_var.calls[call_id];
>
> // get transport info
> pjmedia_transport_get_info(call->med_tp, &skinfo);
> if (status != PJ_SUCCESS) error_exit("Error getting info", status);
>
> pj_sockaddr_in rem_addr;
> pj_sockaddr_in rem_rtcp;
> rem_addr= (pj_sockaddr_in)skinfo.rtp_addr_name;
> rem_rtcp= (pj_sockaddr_in)skinfo.rtcp_addr_name;
>
> // is correct this detach ?
> pjmedia_transport_detach(call->med_tp, call->user_data);
> if (status != PJ_SUCCESS) error_exit("Error detaching transport", status);
>
> // is correct this ?
> pjmedia_transport_attach(call->med_tp, NULL, &rem_addr, &rem_rtcp,
> sizeof(pj_sockaddr_in), &on_rx_rtp, NULL);
> if (status != PJ_SUCCESS) error_exit("Error attaching transport", status);
>
>
> but it doesn't work, I'm using a modded version of pjsua, but when I run
> it I got
>
>
> 20:28:58.792 os_core_unix.c pjlib 0.8.0 for POSIX initialized
> 20:28:58.792 sip_endpoint.c Creating endpoint instance...
> 20:28:58.793 pjlib select() I/O Queue created (0x814956c)
> 20:28:58.793 sip_endpoint.c Module "mod-msg-print" registered
> 20:28:58.793 sip_transport. Transport manager created.
> 20:28:58.809 pjsua_core.c pjsua version 0.8.0 for i686-pc-linux-gnu
> initialized
> 20:28:58.898 pjsua_acc.c Registration sent
> 20:28:59.138 pjsua_acc.c sip:024XXXXX at voip.eutelia.it:
> unregistration success
> 20:28:59.138 test.c Entered in on_reg_state
> 20:28:59.138 test.c Successfully logged in entering main loop
> 20:28:59.208 test.c Entered in on_call_state
> 20:28:59.208 test.c Call 0 state changed to CALLING
> 20:28:59.208 test.c Entered in on_call_tsx_state
> 20:28:59.438 test.c Entered in on_call_state
> 20:28:59.438 test.c Call 0 state changed to CALLING
> 20:28:59.438 test.c Entered in on_call_tsx_state
> 20:28:59.438 test.c Entered in on_call_tsx_state
> 20:28:59.592 test.c Entered in on_call_tsx_state
> 20:29:01.359 test.c Entered in on_call_state
> 20:29:01.359 test.c Wait and cancel call numeber: 0
> 20:29:01.359 test.c Call 0 state changed to EARLY (183 Session
> Progress)
> test: ../src/pjmedia/transport_udp.c:561: transport_attach: Assertion
> `!udp->attached' failed.
> Aborted
>
> what's wrong with my code? I have put the pjmedia_transport_detach in
> the code but I got that error.
>
> thanks
>
> Davide
>
>
> p.s. anyway Benny my best congratulations for all you work, this
> framework is really incredible and useful !
>
>
> _______________________________________________
> 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
>
