Topic
IC4NOTICE: developerWorks Community will be offline May 29-30, 2015 while we upgrade to the latest version of IBM Connections. For more information, read our upgrade FAQ.
4 replies Latest Post - ‏2011-10-25T14:26:39Z by SystemAdmin
cheungda
cheungda
20 Posts
ACCEPTED ANSWER

Pinned topic JSR289 container handling tag change during dialog setup

‏2011-10-18T17:58:34Z |
Hi,

We're encountering an issue where a dialog is being setup and the far-end changed the to-tag between 18x message. After the dialog is setup, when we send a BYE, it uses the old tag.

out INVITE
in TRYING
in 180 Ringing with To-tag=AAA
in 183 Session Progress with To-tag=AAA
in 180 Ringing with To-tag=BBB
in 200-OK with To-tag=BBB
out ACK with To-tag=BBB
...
out BYE with To-tag=AAA
in 481 Call/ID Transaction does not Exist

If I understand correctly, tag handling is hidden from the application. A UAC might receive a different tag if the INVITE was forked by a proxy, and the tag on the 200-OK which confirms the dialog should be used. In the example above, ACK is sent back with the right tag, but not the BYE request.

Interestingly, in the SIP messages where we see this problem, the tags only differ by a few characters. They look almost the same from the human eye, but are definitely not the same string.

e.g. I highlighted the difference within
026473881e11<7d>244eb3d2a200 (first tag sent in the 180/183)
026473881e11<85>244eb3d2a200 (second tag sent in the second 180 and finally 200-OK)

In this situation, should JSR289 be handling this transparently to the application, or does that application have to "do something"?
Updated on 2011-10-25T14:26:39Z at 2011-10-25T14:26:39Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    45 Posts
    ACCEPTED ANSWER

    Re: JSR289 container handling tag change during dialog setup

    ‏2011-10-19T09:11:04Z  in response to cheungda
    Hi,
    It sounds like a derived session scenario, each 180 response with different to-tag causes the container to create a new derived session according to JSR289.
    You should use the correct SipSession in your code when creating the BYE request (the SIP session that is related to to-tag: BBB)
    It sounds like you used the wrong session and this is why it was created with the wrong to-tag

    Asaf,
    • cheungda
      cheungda
      20 Posts
      ACCEPTED ANSWER

      Re: JSR289 container handling tag change during dialog setup

      ‏2011-10-19T13:21:08Z  in response to SystemAdmin
      Does the container notify me about this derived session and how can I get a handle to it, so I am using the correct one on the BYE request?
      • cheungda
        cheungda
        20 Posts
        ACCEPTED ANSWER

        Re: JSR289 container handling tag change during dialog setup

        ‏2011-10-19T14:41:00Z  in response to cheungda
        To answer my own question, I guess I can grab the session object from the 200-OK SipServletResponse.

        Why does the container allow us to send a BYE when the old dialog was not confirmed?
        • SystemAdmin
          SystemAdmin
          45 Posts
          ACCEPTED ANSWER

          Re: JSR289 container handling tag change during dialog setup

          ‏2011-10-25T14:26:39Z  in response to cheungda
          This is according to RFC3261:
          section 15:
          "The caller's UA MAY send a BYE for either
          confirmed or early dialogs, and the callee's UA MAY send a BYE on
          confirmed dialogs, but MUST NOT send a BYE on early dialogs."