Hi. Is it possible to send/receive RTP packets directly on a socket, without streaming them through pjsip (not call rec_cb/play_cb)?

check out pjsip-apps/src/samples/siprtp.c. That shows you how to use the rtp sessions directly. On Thu, May 10, 2012 at 4:08 AM, Pukitis Martins (LQLA CPE ST VD) <Martins.Pukitis@lantiq.com> wrote: > Hi. > > Is it possible to send/receive RTP packets directly on a socket, without > streaming them through pjsip (not call rec_cb/play_cb)? > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

Thanks. Actually it is more complicated than this. There is another device (let's say device X) on the local network, capable of sending and receiving RTP data. I need to tell (using SIP) the remote peer that the other party is this device X and not the device where pjsip is running, so that the device where pjsip is running doesn't get involved in any RTP data transmission. Can it be done with pjsip? -----Original Message----- From: pjsip-bounces@lists.pjsip.org [mailto:pjsip-bounces@lists.pjsip.org] On Behalf Of Joel Dodson Sent: Thursday, May 10, 2012 8:09 PM To: pjsip list Subject: Re: [pjsip] direct RTP check out pjsip-apps/src/samples/siprtp.c. That shows you how to use the rtp sessions directly. On Thu, May 10, 2012 at 4:08 AM, Pukitis Martins (LQLA CPE ST VD) <Martins.Pukitis@lantiq.com> wrote: > Hi. > > Is it possible to send/receive RTP packets directly on a socket, > without streaming them through pjsip (not call rec_cb/play_cb)? > > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > _______________________________________________ Visit our blog: http://blog.pjsip.org pjsip mailing list pjsip@lists.pjsip.org http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

you're proposing a third party call control scenario (3PCC). See RFC 3725 (http://tools.ietf.org/html/rfc3725) if you haven't already. You can do that with PJSIP/PJMEDIA. You just need to put the IP:port for the RTP stream for device X into the SDPs sent by your main SIP device to the client. Check out the invite session abstraction (pjsip_inv_session). It's used in the siprtp.c sample and in the simpleua.c sample. You'll be using PJSIP at a much lower level than the API to write a simple client, but you'll have much more control over the messages and full access to get and set SDPs. It's also much more efficient than the higher level API. good luck. It's quite simple really once you get into it... On Thu, May 10, 2012 at 11:48 AM, Pukitis Martins (LQLA CPE ST VD) <Martins.Pukitis@lantiq.com> wrote: > Thanks. > Actually it is more complicated than this. There is another device (let's say device X) on the local network, capable of sending and receiving RTP data. I need to tell (using SIP) the remote peer that the other party is this device X and not the device where pjsip is running, so that the device where pjsip is running doesn't get involved in any RTP data transmission. Can it be done with pjsip? > > -----Original Message----- > From: pjsip-bounces@lists.pjsip.org [mailto:pjsip-bounces@lists.pjsip.org] On Behalf Of Joel Dodson > Sent: Thursday, May 10, 2012 8:09 PM > To: pjsip list > Subject: Re: [pjsip] direct RTP > > check out pjsip-apps/src/samples/siprtp.c.  That shows you how to use the rtp sessions directly. > > On Thu, May 10, 2012 at 4:08 AM, Pukitis Martins (LQLA CPE ST VD) <Martins.Pukitis@lantiq.com> wrote: >> Hi. >> >> Is it possible to send/receive RTP packets directly on a socket, >> without streaming them through pjsip (not call rec_cb/play_cb)? >> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip@lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org

Thanks. I started implementing it and came across an issue. I've assigned on_send_ack my callback function to modify the IP:port, but this callback isn't called. Pjsip sends invite, remote replies with 100/INVITE 3 times, then with 183/INVITE. On reception of this, it creates a new transaction (tsx0x4bd134) for replying. In log this line: 00:14:50.487 tsx0x4bd134 Transaction created for Request msg PRACK/cseq=14643 (tdta0x4bc0c8) Then remote replies with 200/PRACK, but I don't get this ACK in application, because pjsip thinks it is for transaction tsx0x4bd134 and not for the initial transaction of the dialog (tsx0x4b8fbc), so the check if (tsx == inv->invite_tsx) { in sip_inv.c, function inv_on_state_early is false and inv_send_ack is not called. Pjsip replies with standard 200/PRACK. Full log: 00:14:47.951 os_core_unix.c pjlib 1.14.0 for POSIX initialized 00:14:47.986 sip_endpoint.c Creating endpoint instance... 00:14:48.042 pjlib select() I/O Queue created (0x4ae2b0) 00:14:48.050 sip_endpoint.c Module "mod-msg-print" registered 00:14:48.051 sip_transport. Transport manager created. 00:14:48.066 udp0x4b1fb0 SIP UDP transport started, published address is 192.168.1.121:5070 00:14:48.130 sip_endpoint.c Module "mod-tsx-layer" registered 00:14:48.131 sip_endpoint.c Module "mod-stateful-util" registered 00:14:48.131 sip_endpoint.c Module "mod-ua" registered 00:14:48.138 sip_endpoint.c Module "mod-invite" registered 00:14:48.140 sip_endpoint.c Module "mod-100rel" registered 00:14:48.141 sip_endpoint.c Module "mod-cc" registered 00:14:48.141 svipua.c module id 6 00:14:48.143 dlg0x4b7394 UAC dialog created 00:14:48.143 dlg0x4b7394 Module mod-invite added as dialog usage, data=0x4b7b4c 00:14:48.143 dlg0x4b7394 Session count inc to 2 by mod-invite 00:14:48.144 dlg0x4b7394 Module mod-100rel added as dialog usage, data=0x4b7c40 00:14:48.144 dlg0x4b7394 100rel module attached 00:14:48.145 inv0x4b7394 UAC invite session created for dialog dlg0x4b7394 00:14:48.145 endpoint Request msg INVITE/cseq=14643 (tdta0x4b7f50) created. 00:14:48.146 inv0x4b7394 Sending Request msg INVITE/cseq=14643 (tdta0x4b7f50) 00:14:48.146 dlg0x4b7394 Sending Request msg INVITE/cseq=14643 (tdta0x4b7f50) 00:14:48.147 tsx0x4b8fbc Transaction created for Request msg INVITE/cseq=14642 (tdta0x4b7f50) <-- INITIAL TRANSACTION 00:14:48.147 tsx0x4b8fbc Sending Request msg INVITE/cseq=14642 (tdta0x4b7f50) in state Null 00:14:48.147 sip_resolve.c Target '192.168.1.145:5060' type=Unspecified resolved to '192.168.1.145:5060' type=UDP (UDP transport) 00:14:48.149 tsx0x4b8fbc State changed from Null to Calling, event=TX_MSG 00:14:48.149 dlg0x4b7394 Transaction tsx0x4b8fbc state changed to Calling 00:14:48.149 svipua.c Call state changed to CALLING 00:14:48.650 tsx0x4b8fbc Retransmit timer event 00:14:48.650 tsx0x4b8fbc Retransmiting Request msg INVITE/cseq=14642 (tdta0x4b7f50), count=0, restart?=1 00:14:49.650 tsx0x4b8fbc Retransmit timer event 00:14:49.650 tsx0x4b8fbc Retransmiting Request msg INVITE/cseq=14642 (tdta0x4b7f50), count=1, restart?=1 00:14:50.389 sip_endpoint.c Processing incoming message: Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.390 tsx0x4b8fbc Incoming Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) in state Calling 00:14:50.390 tsx0x4b8fbc State changed from Calling to Proceeding, event=RX_MSG 00:14:50.391 dlg0x4b7394 Received Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.391 dlg0x4b7394 Transaction tsx0x4b8fbc state changed to Proceeding 00:14:50.392 sip_endpoint.c Processing incoming message: Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.392 tsx0x4b8fbc Incoming Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) in state Proceeding 00:14:50.392 tsx0x4b8fbc State changed from Proceeding to Proceeding, event=RX_MSG 00:14:50.393 dlg0x4b7394 Received Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.393 dlg0x4b7394 Transaction tsx0x4b8fbc state changed to Proceeding 00:14:50.394 sip_endpoint.c Processing incoming message: Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.394 tsx0x4b8fbc Incoming Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) in state Proceeding 00:14:50.394 tsx0x4b8fbc State changed from Proceeding to Proceeding, event=RX_MSG 00:14:50.394 dlg0x4b7394 Received Response msg 100/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.395 dlg0x4b7394 Transaction tsx0x4b8fbc state changed to Proceeding 00:14:50.483 sip_endpoint.c Processing incoming message: Response msg 183/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.483 tsx0x4b8fbc Incoming Response msg 183/INVITE/cseq=14642 (rdata0x4b33dc) in state Proceeding 00:14:50.484 tsx0x4b8fbc State changed from Proceeding to Proceeding, event=RX_MSG 00:14:50.484 dlg0x4b7394 Received Response msg 183/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.484 dlg0x4b7394 Route-set updated 00:14:50.485 dlg0x4b7394 Transaction tsx0x4b8fbc state changed to Proceeding 00:14:50.485 svipua.c Call state changed to EARLY 00:14:50.485 inv0x4b7394 Got SDP offer in Response msg 183/INVITE/cseq=14642 (rdata0x4b33dc) 00:14:50.486 endpoint Request msg PRACK/cseq=14644 (tdta0x4bc0c8) created. 00:14:50.487 dlg0x4b7394 Sending Request msg PRACK/cseq=14644 (tdta0x4bc0c8) 00:14:50.487 tsx0x4bd134 Transaction created for Request msg PRACK/cseq=14643 (tdta0x4bc0c8) <-- HERE IT CREATES A NEW TRANSACTION 00:14:50.488 tsx0x4bd134 Sending Request msg PRACK/cseq=14643 (tdta0x4bc0c8) in state Null 00:14:50.488 sip_resolve.c Target '192.168.1.145:5060' type=Unspecified resolved to '192.168.1.145:5060' type=UDP (UDP transport) 00:14:50.489 tsx0x4bd134 State changed from Null to Calling, event=TX_MSG 00:14:50.489 dlg0x4b7394 Transaction tsx0x4bd134 state changed to Calling 00:14:50.545 sip_endpoint.c Processing incoming message: Response msg 200/PRACK/cseq=14643 (rdata0x4b33dc) 00:14:50.545 tsx0x4bd134 Incoming Response msg 200/PRACK/cseq=14643 (rdata0x4b33dc) in state Calling <-- THE NEW TRANSACTION GETS 200/PRACK 00:14:50.546 tsx0x4bd134 State changed from Calling to Completed, event=RX_MSG 00:14:50.546 dlg0x4b7394 Received Response msg 200/PRACK/cseq=14643 (rdata0x4b33dc) 00:14:50.546 dlg0x4b7394 Transaction tsx0x4bd134 state changed to Completed 00:14:55.550 tsx0x4bd134 Timeout timer event 00:14:55.550 tsx0x4bd134 State changed from Completed to Terminated, event=TIMER 00:14:55.550 dlg0x4b7394 Transaction tsx0x4bd134 state changed to Terminated 00:14:55.560 tsx0x4bd134 Timeout timer event 00:14:55.560 tsx0x4bd134 State changed from Terminated to Destroyed, event=TIMER 00:14:55.560 tdta0x4bc0c8 Destroying txdata Request msg PRACK/cseq=14643 (tdta0x4bc0c8) 00:14:55.561 tsx0x4bd134 Transaction destroyed! 00:16:50.578 sip_endpoint.c Processing incoming message: Response msg 408/INVITE/cseq=14642 (rdata0x4b33dc) 00:16:50.580 tsx0x4b8fbc Incoming Response msg 408/INVITE/cseq=14642 (rdata0x4b33dc) in state Proceeding 00:16:50.581 endpoint Request msg ACK/cseq=14642 (tdta0x4bc0c8) created. 00:16:50.581 tsx0x4b8fbc State changed from Proceeding to Completed, event=RX_MSG 00:16:50.582 dlg0x4b7394 Received Response msg 408/INVITE/cseq=14642 (rdata0x4b33dc) 00:16:50.582 dlg0x4b7394 Transaction tsx0x4b8fbc state changed to Completed 00:16:50.582 svipua.c Call DISCONNECTED [reason=408 (Request Timeout)] 00:16:50.583 svipua.c One call completed 00:16:50.583 dlg0x4b7394 Session count dec to 1 by mod-invite 00:16:50.583 tdta0x4b7f50 Destroying txdata Request msg INVITE/cseq=14642 (tdta0x4b7f50) 00:16:50.584 svipua.c Total pool memory allocated=88 KB, used=70 KB -----Original Message----- From: pjsip-bounces@lists.pjsip.org [mailto:pjsip-bounces@lists.pjsip.org] On Behalf Of Joel Dodson Sent: Friday, May 11, 2012 12:53 AM To: pjsip list Subject: Re: [pjsip] direct RTP you're proposing a third party call control scenario (3PCC). See RFC 3725 (http://tools.ietf.org/html/rfc3725) if you haven't already. You can do that with PJSIP/PJMEDIA. You just need to put the IP:port for the RTP stream for device X into the SDPs sent by your main SIP device to the client. Check out the invite session abstraction (pjsip_inv_session). It's used in the siprtp.c sample and in the simpleua.c sample. You'll be using PJSIP at a much lower level than the API to write a simple client, but you'll have much more control over the messages and full access to get and set SDPs. It's also much more efficient than the higher level API. good luck. It's quite simple really once you get into it...