*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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
