PJSIP_ISSUE. When i sync my pjsip based application and register with it works fine but when go into background and put the device idle for more than a hour we are getting the *PJSIP_SC_SERVICE_UNAVAILABLE* = 503 response form the server and the pjsip application is not retrying for the registration again.But in the application we are retrying the connection for every 5 seconds after the connection lost
(reg_retry_interval=5 ) can any body solve this issue for me .. what should i do any suggestions. On Wed, Jun 27, 2012 at 11:03 AM, Giriprathap Raju < [email protected]> wrote: > *Hi seshagiri,* > > ** > > *PJSIP_SC_REQUEST_TIMEOUT and PJSIP_SC_SERVER_TIMEOUT are totally two > different things.* > > ** > > *->PJSIP_SC_REQUEST_TIMEOUT* = 408 is when the session expires or > connection lost and the and the application tries to send the packet to the > server then if it not finds the Acknowledgment packet then it throws the > *PJSIP_SC_REQUEST_TIMEOUT > error.* > > ** > > *where as * > > ** > > *-> PJSIP_SC_SERVER_TIMEOUT = 504 *is usually sent by a server (gateway) > when it does not receive a response from another server . > > On Wed, Jun 27, 2012 at 10:59 AM, Tarun2 Gupta > <[email protected]>wrote: > >> Hi >> >> 504 is usually sent by a server (gateway) when it does not receive a >> timely >> response from another server (such as a location server). >> >> 408 is related to SIP transaction layer request timeouts. >> >> Regards, >> Tarun Gupta >> Aricent >> >> -----Original Message----- >> From: [email protected] [mailto: >> [email protected]] On Behalf Of seshagiri >> Sent: Wednesday, June 27, 2012 8:54 AM >> To: sip-implementors >> Subject: [Sip-implementors] What is the difference between 408 and 504 >> responses >> >> What is the difference between 408 and 504 responses ? >> > >> > >> > In the below negative scenarios our sbc forward the recieived >> requests >> > to UAS. >> > UAS will not respond for few requests( It will not send 200 for INFO >> or >> > UPDATE or OPTIONS) >> > In some scenarios UAS will not send 200 OK after 180. >> > But our sbc sends responses like 408 or 504 to UAC. >> > I could not able to understand when it sends 408 and when it sends >> 504 ? >> > >> > >> > >> > >> > Messages Retrans Timeout Unexpected-Msg >> > INVITE ----------> 0 0 0 >> > 100 <---------- 0 0 0 0 >> > 180 <---------- 0 0 0 0 >> > 183 <---------- 0 0 0 0 >> > 200 <---------- E-RTD1 0 0 0 0 >> > ACK ----------> 0 0 >> > Pause [ 1000ms] 0 0 >> > INFO ----------> 0 0 >> > 100 <---------- 0 0 0 0 >> > 408 <---------- E-RTD1 0 0 0 0 >> > Pause [ 20.0s] 0 0 >> > BYE ----------> 0 0 0 >> > 200 <---------- 0 0 0 0 >> > >> > >> > Messages Retrans Timeout >> > Unexpected-Msg >> > INVITE ----------> 0 0 0 >> > 100 <---------- 0 0 0 0 >> > 180 <---------- 0 0 0 0 >> > >> > 504 <---------- E-RTD1 0 0 0 0 >> > ACK ----------> 0 0 >> > >> > >> > >> > Messages Retrans Timeout >> > Unexpected-Msg >> > INVITE ----------> 0 0 0 >> > 100 <---------- 0 0 0 0 >> > 180 <---------- 0 0 0 0 >> > 183 <---------- 0 0 0 0 >> > >> > PRACK ----------> 0 0 >> > 200 <---------- 0 0 0 0 >> > 504 <---------- 0 0 0 0 >> > >> > ACK ----------> 0 0 >> > >> > >> > Messages Retrans Timeout >> > Unexpected-Msg >> > INVITE ----------> 1 0 0 >> > 100 <---------- 1 0 0 0 >> > 180 <---------- 0 0 0 0 >> > 183 <---------- 1 0 0 0 >> > >> > PRACK ----------> 1 0 >> > 200 <---------- 1 0 0 0 >> > UPDATE ----------> 1 0 >> > 504 <---------- 0 0 0 0 >> > >> > ACK ----------> 0 0 >> > ------- Waiting for active calls to end. Press [q] again to force exit. >> > ------- >> > >> > >> > >> > Messages Retrans Timeout >> > Unexpected-Msg >> > INVITE ----------> 1 0 0 >> > 100 <---------- 1 0 0 0 >> > 180 <---------- 1 0 0 0 >> > 183 <---------- 0 0 0 0 >> > 200 <---------- E-RTD1 1 0 0 0 >> > ACK ----------> 1 0 >> > Pause [ 1000ms] 1 0 >> > INFO ----------> 1 0 >> > 100 <---------- 0 0 0 0 >> > 408 <---------- E-RTD1 1 0 0 0 >> > Pause [ 20.0s] 1 0 >> > BYE ----------> 1 0 0 >> > 200 <---------- 1 0 0 0 >> > >> > ------------------------------ Test Terminated >> > -------------------------------- >> > >> > >> > >> > >> > >> > >> > Messages Retrans Timeout >> > Unexpected-Msg^M >> > INVITE ----------> 1 0 0 >> ^M >> > 100 <---------- 1 0 0 0 >> ^M >> > 180 <---------- 1 0 0 0 >> ^M >> > 183 <---------- 0 0 0 0 >> ^M >> > 200 <---------- E-RTD1 1 0 0 0 >> ^M >> > ACK ----------> 1 0 >> ^M >> > Pause [ 3000ms] 1 0 >> ^M >> > REFER ----------> 1 5 0 >> ^M >> > 100 <---------- 0 0 0 0 >> ^M >> > 408 <---------- 1 0 0 0 >> ^M >> > BYE ----------> 1 0 0 >> ^M >> > 200 <---------- 1 0 0 0 >> ^M >> > ^M >> > ------------------------------ Test Terminated --------------------- >> > >> > >> > Messages Retrans Timeout >> > Unexpected-Msg^M >> > ----------> INVITE 1 0 0 0 >> ^M >> > ^M >> > <---------- 180 1 0 >> ^M >> > <---------- 200 1 0 >> ^M >> > ----------> ACK E-RTD1 1 0 0 0 >> ^M >> > ^M >> > [ 3000ms] Pause 1 0 >> ^M >> > <---------- OPTIONS 1 7 0 >> ^M >> > ----------> 408 1 0 0 0 >> ^M >> > ^M >> > ----------> BYE 1 0 0 0 >> ^M >> > <---------- 200 1 0 >> ^M >> > ------------------------------ Test Terminated >> > --------------------------------^M >> > ^M >> > >> > >> > Messages Retrans Timeout >> > Unexpected-Msg^M >> > NOTIFY ----------> 1 0 >> ^M >> > 100 <---------- 0 0 0 0 >> ^M >> > 408 <---------- E-RTD1 1 0 0 0 >> ^M >> > ------------------------------ Test Terminated >> ---------------------------- >> > >> > >> > Regards >> > Sesh >> > >> > >> > >> > On Thu, Jun 21, 2012 at 10:01 PM, Aniella Juverdeanu < >> > [email protected]> wrote: >> > >> >> Allow header just lets know the remote party that INFO is supported as >> a >> >> method but if the two SIP end points do not support out of band DTMF >> tones >> >> in INFO message, then should use in-band as RFC 2833 RTP packets.**** >> >> >> >> ** ** >> >> >> >> *From:* Phillip Lewis [mailto:[email protected]] >> >> *Sent:* June 18, 2012 6:40 PM >> >> *To:* Aniella Juverdeanu >> >> *Cc:* virajith; discussion >> >> *Subject:* Re: [SIPForum-discussion] dtmf issue on the sip trunk !!**** >> >> >> >> ** ** >> >> >> >> What about the Allow field in the SIP Header. INFO may have been >> >> included, could SIP INFO have been resolved.?**** >> >> >> >> On Mon, Jun 18, 2012 at 11:45 AM, Aniella Juverdeanu < >> >> [email protected]> wrote:**** >> >> >> >> Hi,**** >> >> >> >> **** >> >> >> >> To me it looks negotiated ok with CODEC G711and RFC 2833/4733 for DTMF >> >> events 0-15. **** >> >> >> >> I didn't see until now 77 and 84 used but if not accepted by the other >> >> end it means not supported - but the call should continue with standard >> >> events 0-15.**** >> >> >> >> **** >> >> >> >> More details you may find in RFC 2833/4733.**** >> >> >> >> **** >> >> >> >> Aniella **** >> >> >> >> **** >> >> >> >> *From:* [email protected] [mailto: >> >> [email protected]] *On Behalf Of *virajith >> >> *Sent:* June 12, 2012 9:47 PM >> >> *To:* discussion >> >> *Subject:* [SIPForum-discussion] dtmf issue on the sip trunk !!**** >> >> >> >> **** >> >> >> >> >> >> Hello Team, >> >> >> >> I have an issue where dtmf is not getting negotiated . We are doing a >> >> delayed offer to pbx but the pbx .. >> >> >> >> What the dtmf methods advertised in this 200 ok sdp sent by the pbx ? >> >> >> >> v=0 >> >> o=IPC 425146 425146 IN IP4 XXXXX >> >> s=IPC >> >> c=IN IP4 10.97.232.239 >> >> t=0 0 >> >> m=audio 16442 RTP/AVP 0 8 18 101 >> >> a=rtpmap:0 PCMU/8000 >> >> a=rtpmap:8 PCMA/8000 >> >> a=rtpmap:18 G729/8000 >> >> a=fmtp:18 annexb=yes >> >> a=rtpmap:101 telephone-event/8000 >> >> a=fmtp:101 0-15,77,84 >> >> a=ptime:20 >> >> a=sendrecv >> >> >> >> >> >> in the ACK that we(our end) send is this... >> >> >> >> >> >> v=0 >> >> o=CiscoSystemsCCM-SIP 2000 1 IN IP4 10.97.202.101 >> >> s=SIP Call >> >> c=IN IP4 10.97.202.124 >> >> t=0 0 >> >> m=audio 19504 RTP/AVP 0 101 >> >> a=rtpmap:0 PCMU/8000 >> >> a=ptime:20 >> >> a=rtpmap:101 telephone-event/8000 >> >> a=fmtp:101 0-15 >> >> >> >> >> >> What the dtmf methods advertised and negotiated? >> >> >> >> >> >> Thanks, >> >> Vir >> >> >> >> >> >> >> >> >> >> >> >> **** >> >> >> >> [image: Image removed by sender.]< >> http://sigads.rediff.com/RealMedia/ads/click_nx.ads/www.rediffmail.com/signatureline.htm@Middle >> ?> >> >> **** >> >> >> >> Follow *Rediff Deal ho jaye!< >> http://track.rediff.com/click?url=___http://dealhojaye.rediff.com?sc_cid=rediffmailsignature___&cmp=signature&lnk=rediffmailsignature&newservice=deals >> > >> >> * to get exciting offers in your city everyday.**** >> >> >> >> **** >> >> >> >> >> >> _______________________________________________ >> >> This is the SIP Forum discussion mailing list >> >> TO UNSUBSCRIBE, or edit your delivery options, please visit >> >> http://sipforum.org/mailman/listinfo/discussion >> >> Post to the list at [email protected]**** >> >> >> >> >> >> >> >> **** >> >> >> >> ** ** >> >> >> >> -- >> >> *Phillip Lewis* >> >> Senior Manager, Engineering >> >> *VIP Communications Inc* >> >> Office | 703-708-1515 Ext 213 >> >> Fax | 703-708-1518 >> >> Email | [email protected] **** >> >> >> >> Website | www.joinvip.com**** >> >> >> >> ** ** >> >> >> >> _______________________________________________ >> >> This is the SIP Forum discussion mailing list >> >> TO UNSUBSCRIBE, or edit your delivery options, please visit >> >> http://sipforum.org/mailman/listinfo/discussion >> >> Post to the list at [email protected] >> >> >> >> >> > >> >> >> >> >> >> =============================================================================== >> Please refer to http://www.aricent.com/legal/email_disclaimer.html >> for important disclosures regarding this electronic communication. >> >> =============================================================================== >> >> _______________________________________________ >> Sip-implementors mailing list >> [email protected] >> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors >> > > > > -- > Thanks&Regards > V.Giriprathapraju > Mobile:-09703662169 > > > -- Thanks&Regards V.Giriprathapraju Mobile:-09703662169 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
