Hello All, I am developing a SIP User Agent application using pjsip. I am following the instructions given in the the PJSIP Developer's guide. For learning, I chose core pjsip over the pjsua library abstraction. For the User Agent, I prefer TCP transport for listening and making outgoing calls. This is where my problem comes in. For TCP, I have promptly added ";transport=tcp" to the remote and target uri as per the FAQ http://trac.pjsip.org/repos/wiki/FAQ#tcp 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. I get an error saying, the type is unspecified which pjsip defaults to UDP. I dont use any callback method to send ack from my application. PJSIP sends the ACK by itself. With wireshark sniffer, I could notice no ACK getting transmitted on wire. Do I need to specify anyother thing besides ";transport=tcp"? I have pasted the pjsip log below. Please help. If you require some more details, please let me know. Thanks in advance. *Some Details:* pjsip version: 1.10 OS: Linux *Log:* /* Initialization */ 15:18:57.019 os_core_unix.c pjlib 1.10.0 for POSIX initialized 15:18:57.019 sip_endpoint.c Creating endpoint instance... 15:18:57.019 pjlib select() I/O Queue created (0x8f9610) 15:18:57.019 sip_endpoint.c Module "mod-msg-print" registered 15:18:57.019 sip_transport. Transport manager created. 15:18:57.019 tcplis:5260 SIP TCP listener ready for incoming connections at 127.0.0.1:5260 15:18:57.019 sip_endpoint.c Module "mod-tsx-layer" registered 15:18:57.019 sip_endpoint.c Module "mod-stateful-util" registered 15:18:57.019 sip_endpoint.c Module "mod-ua" registered 15:18:57.019 sip_endpoint.c Module "mod-100rel" registered 15:18:57.019 sip_endpoint.c Module "mod-invite" registered 15:18:57.019 sip_endpoint.c Module "mod-mysip-ua" registered /* UAC Dialog creation and making a call */ 15:18:59.020 dlg0x906628 UAC dialog created 15:18:59.020 dlg0x906628 Module mod-invite added as dialog usage, data=0x908628 15:18:59.020 dlg0x906628 Session count inc to 2 by mod-invite 15:18:59.020 dlg0x906628 Module mod-100rel added as dialog usage, data=0x90aa40 15:18:59.020 dlg0x906628 100rel module attached 15:18:59.020 inv0x906628 UAC invite session created for dialog dlg0x906628 15:18:59.020 endpoint Request msg INVITE/cseq=125 (tdta0x90aa90) created. 15:18:59.020 inv0x906628 Sending Request msg INVITE/cseq=125 (tdta0x90aa90) 15:18:59.020 dlg0x906628 Sending Request msg INVITE/cseq=125 (tdta0x90aa90) 15:18:59.020 tsx0x90daa8 Transaction created for Request msg INVITE/cseq=124 (tdta0x90aa90) 15:18:59.020 tsx0x90daa8 Sending Request msg INVITE/cseq=124 (tdta0x90aa90) in state Null 15:18:59.020 sip_resolve.c Target '127.0.0.1:0' type=TCP resolved to ' 127.0.0.1:5060' type=TCP (TCP transport) 15:18:59.020 tcpc0x90e448 TCP client transport created 15:18:59.020 tcpc0x90e448 TCP transport 127.0.0.1:59402 is connecting to 127.0.0.1:5060... 15:18:59.020 tsx0x90daa8 State changed from Null to Calling, event=TX_MSG 15:18:59.020 dlg0x906628 Transaction tsx0x90daa8 state changed to Calling /* Receiving 180 ringing */ 15:18:59.021 tcpc0x90e448 TCP transport 127.0.0.1:59402 is connected to 127.0.0.1:5060 15:18:59.022 sip_endpoint.c Processing incoming message: Response msg 180/INVITE/cseq=124 (rdata0x90e728) 15:18:59.022 tsx0x90daa8 Incoming Response msg 180/INVITE/cseq=124 (rdata0x90e728) in state Calling 15:18:59.022 tsx0x90daa8 State changed from Calling to Proceeding, event=RX_MSG 15:18:59.022 dlg0x906628 Received Response msg 180/INVITE/cseq=124 (rdata0x90e728) 15:18:59.022 dlg0x906628 Route-set updated 15:18:59.022 dlg0x906628 Transaction tsx0x90daa8 state changed to Proceeding /* Receiving 200 OK */ 15:19:05.668 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:05.668 tsx0x90daa8 Incoming Response msg 200/INVITE/cseq=124 (rdata0x90e728) in state Proceeding 15:19:05.668 tsx0x90daa8 State changed from Proceeding to Terminated, event=RX_MSG 15:19:05.668 dlg0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:05.668 dlg0x906628 Route-set updated 15:19:05.668 dlg0x906628 Route-set frozen 15:19:05.668 dlg0x906628 Transaction tsx0x90daa8 state changed to Terminated /* PJSIP sends ACK for the 200 OK */ 15:19:05.668 inv0x906628 Got SDP answer in Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:05.668 inv0x906628 SDP negotiation done, status=0 15:19:05.668 inv0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728), sending ACK 15:19:05.668 endpoint Request msg ACK/cseq=124 (tdta0x9150e0) created. 15:19:05.668 dlg0x906628 Sending Request msg ACK/cseq=124 (tdta0x9150e0) *15:19:05.668 sip_resolve.c Target '127.0.0.1:0' type=Unspecified resolved to '127.0.0.1:5060' type=UDP (UDP transport) * << Here is the problem /* Retransmission */ 15:19:05.668 tsx0x90daa8 Timeout timer event 15:19:05.668 tsx0x90daa8 State changed from Terminated to Destroyed, event=TIMER 15:19:05.668 tdta0x90aa90 Destroying txdata Request msg INVITE/cseq=124 (tdta0x90aa90) 15:19:05.668 tsx0x90daa8 Transaction destroyed! 15:19:06.168 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:06.168 dlg0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:06.168 inv0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728), sending ACK 15:19:06.168 dlg0x906628 Sending Request msg ACK/cseq=124 (tdta0x9150e0) 15:19:06.168 endpoint Request msg ACK/cseq=124 (tdta0x9150e0): skipping target resolution because address is already set 15:19:07.168 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:07.168 dlg0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:07.168 inv0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728), sending ACK 15:19:07.168 dlg0x906628 Sending Request msg ACK/cseq=124 (tdta0x9150e0) 15:19:07.168 endpoint Request msg ACK/cseq=124 (tdta0x9150e0): skipping target resolution because address is already set 15:19:09.168 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:09.168 dlg0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:09.168 inv0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728), sending ACK 15:19:09.168 dlg0x906628 Sending Request msg ACK/cseq=124 (tdta0x9150e0) 15:19:09.168 endpoint Request msg ACK/cseq=124 (tdta0x9150e0): skipping target resolution because address is already set 15:19:13.168 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:13.168 dlg0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:13.168 inv0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728), sending ACK 15:19:13.168 dlg0x906628 Sending Request msg ACK/cseq=124 (tdta0x9150e0) 15:19:13.168 endpoint Request msg ACK/cseq=124 (tdta0x9150e0): skipping target resolution because address is already set 15:19:17.168 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:17.168 dlg0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:17.168 inv0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728), sending ACK 15:19:17.168 dlg0x906628 Sending Request msg ACK/cseq=124 (tdta0x9150e0) 15:19:17.168 endpoint Request msg ACK/cseq=124 (tdta0x9150e0): skipping target resolution because address is already set 15:19:21.168 sip_endpoint.c Processing incoming message: Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:21.168 dlg0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728) 15:19:21.168 inv0x906628 Received Response msg 200/INVITE/cseq=124 (rdata0x90e728), sending ACK 15:19:21.168 dlg0x906628 Sending Request msg ACK/cseq=124 (tdta0x9150e0) 15:19:21.168 endpoint Request msg ACK/cseq=124 (tdta0x9150e0): skipping target resolution because address is already set PS: Sorry if this mail appears twice in the mailing list. I forgot to subscribe before posting! Regards, Sundar

2011/10/7 Sundar Subramaniyan <sundar.subramaniyan@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@aliax.net>

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@aliax.net> wrote: > 2011/10/7 Sundar Subramaniyan <sundar.subramaniyan@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@aliax.net> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

On Mon, Oct 10, 2011 at 11:27 PM, Sundar Subramaniyan <sundar.subramaniyan@gmail.com> wrote: > 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 > > > 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. > Your 200/OK is malformed. If you want TCP, the Contact header should be: Contact: <sip:127.0.0.1;transport=tcp> instead of Contact: <sip:127.0.0.1>;transport=tcp Benny

Hi Benny, I wasn't sure of the format of the contact header. I changed the sprintf() in my code to put the whole address and transport=tcp between angled brackets. Now, with Contact: <sip:127.0.0.1;transport=tcp> , TCP works like a charm. The UAC is able to parse the contact header well and ACK is sent in TCP. The issue is solved. Thank you very much! Inaki, Thanks to you too! SIP trace was easier to find out this problem. Regards, Sundar On Tue, Oct 11, 2011 at 1:30 PM, Benny Prijono <bennylp@teluu.com> wrote: > On Mon, Oct 10, 2011 at 11:27 PM, Sundar Subramaniyan > <sundar.subramaniyan@gmail.com> wrote: > > 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 > > > > > > 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. > > > > > Your 200/OK is malformed. If you want TCP, the Contact header should be: > > Contact: <sip:127.0.0.1;transport=tcp> > > instead of > > Contact: <sip:127.0.0.1>;transport=tcp > > Benny > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >

2011/10/11 Sundar Subramaniyan <sundar.subramaniyan@gmail.com>: > I wasn't sure of the format of the contact header. Hi Sundar, RFC 3261 describes the Contact header syntax ;) Nice to hear you have fixed it. Cheers. -- Iñaki Baz Castillo <ibc@aliax.net>

Hi Inaki, Forgive my ignorance :) Am new to SIP stuff. Will go through the header format in the RFC. Thanks, Regards, Sundar On Tue, Oct 11, 2011 at 2:45 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote: > 2011/10/11 Sundar Subramaniyan <sundar.subramaniyan@gmail.com>: > > I wasn't sure of the format of the contact header. > > Hi Sundar, RFC 3261 describes the Contact header syntax ;) > > Nice to hear you have fixed it. Cheers. > > -- > Iñaki Baz Castillo > <ibc@aliax.net> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip@lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >