Loading ...
Sorry, an error occurred while loading the content.

Avoid 6XX responses

Expand Messages
  • Iñaki Baz Castillo
    Hi, I remember very long threads here talking about the 603 Decline code sent by Twinkle instead of a 489/486/403. Now I m 200% sure that no SIP phone should
    Message 1 of 4 , Jun 3, 2008
    View Source
    • 0 Attachment
      Hi, I remember very long threads here talking about the "603 Decline"
      code sent by Twinkle instead of a 489/486/403.

      Now I'm 200% sure that no SIP phone should NEVER reply a 6XX response.

      I mantain a SIP provider with OpenSer and forwards request to a media
      server (early messages) if there is a network error, congestion and
      so. For that I proxy the request (this is: generate a new branch in
      OpenSer) but it CANNOT be done if a called instance replied a 6XX
      since a 6XX breaks parallel and serial forking (even not yet created
      branches).

      When I receibe a call from PSTN and route to a SIP user, if the called
      replies a 480/486/403 I forward the request to the media server and
      reproduce "The user you call is unavailable now".
      But if the called user is a Twinkle and replies a 603 then OpenSer
      cannot create the new branch and there is not early announcement for
      the caller. This is painful but it the 6XX oficial behaviour.

      So I propose to avoid using any 6XX in a SIP phone, no SIP phone
      should NEVER use it, there is no reason for that, and just creates
      problem.

      I link to a thread in sip-implementors I opened about this issue, hop

      https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-June/019413.html

      Also I link to darft:
      "the 6xx-Class Responses Considered Harmful in SIP"
      http://tools.ietf.org/html/draft-worley-6xx-considered-harmful-00

      PD: I've read in RFC 3261 that a UAS could reply a "403 Forbidden" to
      decline a call using a 4XX.


      --
      Iñaki Baz Castillo
      <ibc@...>
    • Michel de Boer
      Yes, I remember the discussion on 480/486 vs 603 response. That s still something on my todo list. I agree that in general a 6XX response may not be what you
      Message 2 of 4 , Jun 5, 2008
      View Source
      • 0 Attachment
        Yes, I remember the discussion on 480/486 vs 603 response. That's
        still something on my todo list.

        I agree that in general a 6XX response may not be what you want.
        But in case of declining a call a 603 could make sense. If I register
        2 SIP devices with the same account. When a call comes in then
        both devices may ring (forking) or first one and then another
        (sequential search). I may decide to decline the call without intention
        to pickup the call on any other device. In that case a 603 makes
        sense. So it all depends on what one wishes to achieve.

        --
        Michel de Boer
        www.twinklephone.com
      • joerg
        ... That s why we decided to have a config option on exact type of response for decline IIRC. Something like a 3-digit numeric field in *User*-profile
        Message 3 of 4 , Jun 5, 2008
        View Source
        • 0 Attachment
          Am Do 5. Juni 2008 schrieb Michel de Boer:
          > Yes, I remember the discussion on 480/486 vs 603 response. That's
          > still something on my todo list.
          >
          > I agree that in general a 6XX response may not be what you want.
          > But in case of declining a call a 603 could make sense. If I register
          > 2 SIP devices with the same account. When a call comes in then
          > both devices may ring (forking) or first one and then another
          > (sequential search). I may decide to decline the call without intention
          > to pickup the call on any other device. In that case a 603 makes
          > sense. So it all depends on what one wishes to achieve.
          >

          That's why we decided to have a config option on exact type of response
          for "decline" IIRC. Something like a 3-digit numeric field in *User*-profile
          settings (maybe a text too), and possibly also a dropdown-menu to select from
          2 or 3 different decline-options, that's implemented much the way like
          the "back" button on many browsers in the sense of being a pushbutton and a
          menu-open same time, depending on the duration you hold down the LMB.

          cheers
          jOERG
        • Iñaki Baz Castillo
          ... Sure? And what about if the proxy wants to forward the INVITE to a voicemail? if a user has replied a 6XX then the proxy CANNOT create a new branch so it
          Message 4 of 4 , Jun 6, 2008
          View Source
          • 0 Attachment
            2008/6/5, Michel de Boer <michel@...>:
            > Yes, I remember the discussion on 480/486 vs 603 response. That's
            > still something on my todo list.
            >
            > I agree that in general a 6XX response may not be what you want.
            > But in case of declining a call a 603 could make sense. If I register
            > 2 SIP devices with the same account. When a call comes in then
            > both devices may ring (forking) or first one and then another
            > (sequential search). I may decide to decline the call without intention
            > to pickup the call on any other device. In that case a 603 makes
            > sense. So it all depends on what one wishes to achieve.

            Sure? And what about if the proxy wants to forward the INVITE to a
            voicemail? if a user has replied a 6XX then the proxy CANNOT create a
            new branch so it can not deliver the call to a voicemail. This is
            mandatory in RFC 3261 since "a 6XX breaks parallel and serial forking,
            even if it's a future branch".

            Please, read this thread I opened in sip-implementors:
            https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-June/019413.html
            After this thread the developer of OpenSer included a new option in
            the transaction module parameter to avoid a 6XX breaks forking (this
            is of course anti RFC3261 but since many devices use 6XX when the
            should use 4XX and it breaks voicemail and so, he decides to include
            this option to allow commo scenarios even if a 6XX has been received).

            Best regards.





            --
            Iñaki Baz Castillo
            <ibc@...>
          Your message has been successfully submitted and would be delivered to recipients shortly.