Subject: [tram] Carrying Session identifier in TURN messages

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 18 Jul 2016 13:41:49 +0000

Hi all,

When deploying TURN server in the cloud we saw the following problem:
 There is a  no proper identifier to troubleshoot and
co-relate TURN messages with rest of call control messages.
For example, if we have a cloud rendering IP telephony services having SIP
elements (like SIP proxies, B2BUAs, 3PCC elements and SIP UAs) and media
elements (like TURN servers) we would need a way to co-relate the SIP
messages with TURN control messages for a given session. SIP messages
could be co-related by using an identifier like SIP session ID mostly.

It would be good to have a new STUN attribute that can carry the session
identifier (which can be SIP sessionID in case of TURN session was
allocated by SIP element).

Would like to hear any thoughts the WG have on having such a attribute in
TURN messages ? 

Regards,
Ram

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 19 Jul 2016 13:36:38 +0200

This looks would certainly help in troubleshooting.  What we probably need
is an identifier that the application can pass on to the TURN client to be
included in the TURN control messages associated with an allocation and for
the server to echo it back in the response. How this identifier gets mapped
to the SIP session ID or some other session ID could be just implementation
details. This identifier can then be used to correlate the TURN messages
pertaining to a set of allocations, possibly from different TURN servers,
with session signaling, for troubleshooting purpose..

Muthu

On Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr) <[email-masked]>
wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 19 Jul 2016 14:28:56 +0200

Giving it another thought, if we also want 3pp tools (say, Wireshark) to
 be able to correlate a set of TURN messages with a set to SIP messages, we
may also need to specify how to obtain one ID from the other. But, that
requirement could probably be discussed separately?

Muthu

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 19 Jul 2016 12:54:29 +0000

Hi Muthu,

>
>
>From:  Muthu Arul Mozhi Perumal <[email-masked]>
>Date:  Tuesday, 19 July 2016 at 1:36 PM
>To:  Ram Mohan Ravindranath <[email-masked]>
>Cc:  "[email-masked]" <[email-masked]>
>Subject:  Re: [tram] Carrying Session identifier in TURN messages
>
>
>included in the TURN control messages associated with an allocation and
>for the server to echo it back in the
> response.

Yes that¹s the idea.

> How this identifier gets mapped to the SIP session ID or some
>other session ID could be just implementation details.

Agree. 

> This identifier can
>then be used to correlate the TURN messages pertaining to a set of
>allocations, possibly from different TURN
> servers, with session signaling, for troubleshooting purpose..

Yes. that¹s the main use-case I have.

Regards,
Ram

>
>Muthu
>
>On Mon, Jul 18, 2016 at 3:41 PM, Ram Mohan R (rmohanr)
><[email-masked]> wrote:
>
>Hi all,
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 19 Jul 2016 12:58:04 +0000

Inline

>Date:  Tuesday, 19 July 2016 at 2:28 PM

I am not sure if that needs to be standardised. How tools/application
that correlates these information obtains the ID could be purely an
implementation detail.

Regards,
Ram

>
>Muthu
>
>On Tue, Jul 19, 2016 at 1:36 PM, Muthu Arul Mozhi Perumal
><[email-masked]> wrote:
>
>included in the TURN control messages associated
> with an allocation and for the server to echo it back in the response.
>How this identifier gets mapped to the SIP session ID or some other
>session ID could be just implementation details. This identifier can then
>be used to correlate the TURN messages pertaining
> to a set of allocations, possibly from different TURN servers, with
>session signaling, for troubleshooting purpose..
>
>Muthu
>

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Tue, 19 Jul 2016 16:56:09 +0200

The mapping function probably needs to be standardized for tool
implementors. However, I agree it is a separate requirement and needs to be
discussed whether it should be in scope or out of scope..

Regards,
Muthu