Topic
  • 4 replies
  • Latest Post - ‏2011-10-25T14:26:39Z by SystemAdmin
cheungda
cheungda
20 Posts

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

    Re: JSR289 container handling tag change during dialog setup

    ‏2011-10-19T09:11:04Z  
    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

    Re: JSR289 container handling tag change during dialog setup

    ‏2011-10-19T13:21:08Z  
    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,
    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

    Re: JSR289 container handling tag change during dialog setup

    ‏2011-10-19T14:41:00Z  
    • cheungda
    • ‏2011-10-19T13:21:08Z
    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?
    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

    Re: JSR289 container handling tag change during dialog setup

    ‏2011-10-25T14:26:39Z  
    • cheungda
    • ‏2011-10-19T14:41:00Z
    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?
    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."