Hello Inaki, Thanks for the response. My scenario involves point to point call with two UA. I haven't added ";transport=tcp" in the record route but in the contact URI in the 200 OK response. Please find the SIP trace below from the UAC, where the problem is noticed. 21:18:41.595 os_core_unix.c pjlib 1.10.0 for POSIX initialized 21:18:41.595 sip_endpoint.c Creating endpoint instance... 21:18:41.595 pjlib select() I/O Queue created (0x21e0970) 21:18:41.595 sip_endpoint.c Module "mod-msg-print" registered 21:18:41.596 sip_transport. Transport manager created. 21:18:41.596 tcplis:6060 SIP TCP listener ready for incoming connections at 127.0.0.1:6060 21:18:41.596 sip_endpoint.c Module "mod-tsx-layer" registered 21:18:41.596 sip_endpoint.c Module "mod-stateful-util" registered 21:18:41.596 sip_endpoint.c Module "mod-ua" registered 21:18:41.596 sip_endpoint.c Module "mod-100rel" registered 21:18:41.596 sip_endpoint.c Module "mod-invite" registered 21:18:41.596 sip_endpoint.c Module "mod-mysip-ua" registered 21:18:41.596 sip_endpoint.c Module "mod-msg-logger" registered /* Making call */ 21:18:42.596 dlg0x21ed7d8 UAC dialog created 21:18:42.596 dlg0x21ed7d8 Module mod-invite added as dialog usage, data=0x21ef7d8 21:18:42.596 dlg0x21ed7d8 Session count inc to 2 by mod-invite 21:18:42.596 dlg0x21ed7d8 Module mod-100rel added as dialog usage, data=0x21f1bf0 21:18:42.596 dlg0x21ed7d8 100rel module attached 21:18:42.596 inv0x21ed7d8 UAC invite session created for dialog dlg0x21ed7d8 21:18:42.596 endpoint Request msg INVITE/cseq=125 (tdta0x21f1c40) created. 21:18:42.596 inv0x21ed7d8 Sending Request msg INVITE/cseq=125 (tdta0x21f1c40) 21:18:42.596 dlg0x21ed7d8 Sending Request msg INVITE/cseq=125 (tdta0x21f1c40) 21:18:42.596 tsx0x21f4c58 Transaction created for Request msg INVITE/cseq=124 (tdta0x21f1c40) 21:18:42.596 tsx0x21f4c58 Sending Request msg INVITE/cseq=124 (tdta0x21f1c40) in state Null 21:18:42.596 sip_resolve.c Target '127.0.0.1:0' type=TCP resolved to ' 127.0.0.1:5060' type=TCP (TCP transport) 21:18:42.596 sip_transport. Acquiring transport type=TCP, remote= 127.0.0.1:5060 21:18:42.596 sip_transport. Creating new transport from factory 21:18:42.596 sip_transport. Transport tcpc0x21f55f8 registered: type=TCP, remote=127.0.0.1:5060 21:18:42.596 tcpc0x21f55f8 TCP client transport created 21:18:42.596 tcpc0x21f55f8 TCP transport 127.0.0.1:60000 is connecting to 127.0.0.1:5060... 21:18:42.596 my_sip_ua.c TX 899 bytes Request msg INVITE/cseq=124 (tdta0x21f1c40) to tcp:127.0.0.1:5060: INVITE sip:127.0.0.1;transport=tcp SIP/2.0 Via: SIP/2.0/TCP 127.0.0.1:60000 ;rport;branch=z9hG4bKPjiNeUsXjdMuRBU2j.KGSI94O1i7pQoYqc Max-Forwards: 70 From: sip:127.0.0.1;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V To: sip:127.0.0.1 Contact: <sip:127.0.0.1:6060> Call-ID: 2mdIf8lexOTBIMg2pPgKOBdDB3SowCcf CSeq: 124 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE Supported: 100rel Content-Type: application/sdp Content-Length: 430 v=0 o=sundar 3527250522 3527250522 IN IP4 sundar-desktop s=test c=IN IP4 sundar-desktop t=0 0 m=audio 4000 RTP/AVP 8 a=rtpmap:8 PCMA/8000 a=sendrecv --end msg-- 21:18:42.596 tsx0x21f4c58 State changed from Null to Calling, event=TX_MSG 21:18:42.596 dlg0x21ed7d8 Transaction tsx0x21f4c58 state changed to Calling 21:18:42.602 tcpc0x21f55f8 TCP transport 127.0.0.1:60000 is connected to 127.0.0.1:5060 21:18:42.602 sip_endpoint.c Processing incoming message: Response msg 180/INVITE/cseq=124 (rdata0x21f58d8) 21:18:42.602 my_sip_ua.c RX 437 bytes Response msg 180/INVITE/cseq=124 (rdata0x21f58d8) from tcp:127.0.0.1:5060: SIP/2.0 180 Ringing Via: SIP/2.0/TCP 127.0.0.1:60000 ;rport=60000;received=127.0.0.1;branch=z9hG4bKPjiNeUsXjdMuRBU2j.KGSI94O1i7pQoYqc Call-ID: 2mdIf8lexOTBIMg2pPgKOBdDB3SowCcf From: <sip:127.0.0.1>;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V To: <sip:127.0.0.1>;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V CSeq: 124 INVITE Contact: <sip:127.0.0.1>;transport=tcp Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE Content-Length: 0 --end msg-- 21:18:42.602 tsx0x21f4c58 Incoming Response msg 180/INVITE/cseq=124 (rdata0x21f58d8) in state Calling 21:18:42.602 tsx0x21f4c58 State changed from Calling to Proceeding, event=RX_MSG 21:18:42.602 dlg0x21ed7d8 Received Response msg 180/INVITE/cseq=124 (rdata0x21f58d8) 21:18:42.602 dlg0x21ed7d8 Route-set updated 21:18:42.602 dlg0x21ed7d8 Transaction tsx0x21f4c58 state changed to Proceeding 21:18:47.304 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=124 (rdata0x21f58d8) 21:18:47.304 nt_sip_ua.c RX 864 bytes Response msg 200/INVITE/cseq=124 (rdata0x21f58d8) from tcp:127.0.0.1:5060: SIP/2.0 200 OK Via: SIP/2.0/TCP 127.0.0.1:60000 ;rport=60000;received=127.0.0.1;branch=z9hG4bKPjiNeUsXjdMuRBU2j.KGSI94O1i7pQoYqc Call-ID: 2mdIf8lexOTBIMg2pPgKOBdDB3SowCcf From: <sip:127.0.0.1>;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V To: <sip:127.0.0.1>;tag=PKcMBzp6yhIZQG-du1TsYkW1MPmX6L5V CSeq: 124 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE Contact: <sip:127.0.0.1>;transport=tcp Supported: 100rel Content-Type: application/sdp Content-Length: 379 v=0 o=sundar 3527250522 3527250523 IN IP4 sundar-desktop s= c=IN IP4 sundar-desktop t=0 0 m=audio 4000 RTP/AVP 8 a=rtpmap:8 PCMA/8000 a=sendrecv --end msg-- 21:18:47.304 tsx0x21f4c58 Incoming Response msg 200/INVITE/cseq=124 (rdata0x21f58d8) in state Proceeding 21:18:47.304 tsx0x21f4c58 State changed from Proceeding to Terminated, event=RX_MSG 21:18:47.304 dlg0x21ed7d8 Received Response msg 200/INVITE/cseq=124 (rdata0x21f58d8) 21:18:47.304 dlg0x21ed7d8 Route-set updated 21:18:47.304 dlg0x21ed7d8 Route-set frozen 21:18:47.304 dlg0x21ed7d8 Transaction tsx0x21f4c58 state changed to Terminated 21:18:47.305 inv0x21ed7d8 Got SDP answer in Response msg 200/INVITE/cseq=124 (rdata0x21f58d8) 21:18:47.305 inv0x21ed7d8 SDP negotiation done, status=0 21:18:47.305 inv0x21ed7d8 Received Response msg 200/INVITE/cseq=124 (rdata0x21f58d8), sending ACK 21:18:47.305 endpoint Request msg ACK/cseq=124 (tdta0x21fc290) created. 21:18:47.305 dlg0x21ed7d8 Sending Request msg ACK/cseq=124 (tdta0x21fc290) 21:18:47.305 sip_resolve.c Target '127.0.0.1:0' type=Unspecified resolved to '127.0.0.1:5060' type=UDP (UDP transport) 21:18:47.305 sip_transport. Acquiring transport type=UDP, remote= 127.0.0.1:5060 21:18:47.305 sip_transport. No suitable factory was found either I noticed that once the route set is updated and frozen, the dialog->target is loaded with the URI present in the remote->contact_hdr->contact_uri.(not sure if the variable names are correct) It seems that while cloning the contact header, the ";transport=tcp" part is not cloned. I dont know if this is done purposefully. But I guess it is normal. So, even though the UAS sends the answer with required parameters, the UAC is not able to reply ACK in TCP transport. Please let me know your comments. Regards, Sundar On Sun, Oct 9, 2011 at 2:15 AM, I?aki Baz Castillo <ibc at aliax.net> wrote: > 2011/10/7 Sundar Subramaniyan <sundar.subramaniyan at gmail.com>: > > PJSIP uses TCP for sending invite to remote party. I get 180 ringing and > 200 > > OK responses from the remote which are fine. > > But, the ACK to 200 OK is not sent in TCP. > > Please paste a SIP trace. > > The ACK for a 200 OK response is a *new* transaction so it becomes an > in-dialog request. It means that it would be sent to the Record-Route > URI received in the 200 OK response (or the Contact URI of the 200 if > it has no Record-Route). So that URI MUST contain ;transport=tcp. If > not, the UAS or the proxy in the middle is just wrong. > > This is easy to see in a SIP trace, paste it please. > > -- > I?aki Baz Castillo > <ibc at aliax.net> > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20111010/5d63e44b/attachment.html>
