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