Subject: Re: [MMUSIC] suggestion for new parameter

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 4 Nov 2002 17:43:15 -0500

MessageHi Sanjoy,

Is there any interest or discussion on this at the coming IETF ?

Thanks - Medhavi.

----- Original Message -----
From: Medhavi Bhatia
To: Sanjoy Sen ; [email-masked]
Sent: Thursday, October 03, 2002 11:02 AM
Subject: Re: [MMUSIC] suggestion for new parameter

Sanjoy,

Some more provisioning is definitely needed. Agreed. But the current way
also assumes
endpoints are allowed to make that decision. What if two endpoints which are
directly connected are not allowed to talk directly ? This are realistic
scenarios,
where policy is often decided at the service provider level. Moreover
putting an additional
parameter in SDP will not be signaling (its basically a kind of history, and
whoever
wipes out the history can take control of the media. So an intermediate
proxy/B2BUA which
decided to route the media can just replace/delete that line.

I like the generality of the STUN/ping based idea, but I think the mechanism
should handle
the additional requirements. What do you think ?

-Medhavi.

----- Original Message -----
From: Sanjoy Sen
To: 'Medhavi Bhatia' ; [email-masked]
Sent: Thursday, October 03, 2002 11:45 AM
Subject: RE: [MMUSIC] suggestion for new parameter

Medhavi,

We did think about a solution to this problem based on signaling alone, but
declared that there're too many unknown variables. Firstly, you would need
to provision each UA or Proxy with this "domain signature", its unknown how
would you compute this domain signature and, lastly, two users in the same
domain may not be directly connected (I'm not saying that domain signature
is equivalent to a domain, but somehow two users with the same domain
signature necessarily implies that there must be a direct connectivity). So
we concluded that the best way to figure this out (direct connectivity) is
to try directly, i.e. by pinging the other end point at the address/port at
which it likes to receive media. And, since there'll be retransmission
involved, we would like to allow the call setup progress independently.
Also, a mechansim using STUN (and only STUN) would allow other session
protocols make use of this mechanism. As Cullen pointed out in a separate
SIPPING thread, this may not be STUN per se, but a kind of STUN PING based
on STUN (since it would use many of the same STUN parameters & properties).

Thanks,
Sanjoy

  -----Original Message-----
  From: Medhavi Bhatia [mailto:[email-masked]]
  Sent: Tuesday, October 01, 2002 9:54 AM
  To: [email-masked]
  Subject: [MMUSIC] suggestion for new parameter

  This is related to: draft-sen-sipping-intrarealm-stun-00.txt.

  I wanted to propose a change in the mechanism, by introducing
  new sdp parameters.

  The basic aim is to allow media to flow directly between two endpoints
  which are in the same realm/domain, where the call goes (or is
transferred)
  through an externam proxy/B2BUA etc.

  Whovever is capable of doing nat/stun/other mechanism
(client/proxy/B2BUA),
  inserts an extra line, m0=<base ip address> <base port> <domain
signature>,
  where the base ip
  address and port represent the original ip/port in the c and m lines,
  which are changed for nat purposes. This line can be replaced/deleted
  by by another proxy in the chain, who desires that media MUST be routed
  through it (in other words, it has control/policy).

  When an offer containing this SDP reaches the final proxy (to which the
  gateway/endpoint is registered), it determines using m0, that the src
  media is originaing in the same domain as the final destination. It
  removes the old m and c lines, and introduces new lines based on the
contents
  of the m0 line. This procedure can be done at the final destination, if it
supports
  the m0 parameter.

  In other words, the procedure can be both supported on either the
proxy/B2BUA or the
  endpoint itself. The final endpoint either sees the original m/c line
(which are in
  its domain) or is able to figure that out if the original m0 line was
present.

  Any comments ?

  -Medhavi.

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Mon, 4 Nov 2002 23:28:23 -0500

MessageI am trying to find out who is controlling this document and/or
can help me on the questions I asked.
    -----Original Message-----
    From: Medhavi Bhatia [mailto:[email-masked]]
    Sent: Monday, November 04, 2002 5:43 PM
    To: Medhavi Bhatia; Sanjoy Sen; [email-masked]
    Subject: Re: [MMUSIC] suggestion for new parameter

    Hi Sanjoy,

    Thanks - Medhavi.

    ----- Original Message -----
    From: Medhavi Bhatia
    To: Sanjoy Sen ; [email-masked]
    Sent: Thursday, October 03, 2002 11:02 AM
    Subject: Re: [MMUSIC] suggestion for new parameter

    Sanjoy,

    Some more provisioning is definitely needed. Agreed. But the current way
also assumes
    endpoints are allowed to make that decision. What if two endpoints which
are
    directly connected are not allowed to talk directly ? This are realistic
scenarios,
    where policy is often decided at the service provider level. Moreover
putting an additional
    parameter in SDP will not be signaling (its basically a kind of history,
and whoever
    wipes out the history can take control of the media. So an intermediate
proxy/B2BUA which
    decided to route the media can just replace/delete that line.

    I like the generality of the STUN/ping based idea, but I think the
mechanism should handle
    the additional requirements. What do you think ?

    -Medhavi.

    ----- Original Message -----
    From: Sanjoy Sen
    To: 'Medhavi Bhatia' ; [email-masked]
    Sent: Thursday, October 03, 2002 11:45 AM
    Subject: RE: [MMUSIC] suggestion for new parameter

    Medhavi,

    We did think about a solution to this problem based on signaling alone,
but declared that there're too many unknown variables. Firstly, you would
need to provision each UA or Proxy with this "domain signature", its unknown
how would you compute this domain signature and, lastly, two users in the
same domain may not be directly connected (I'm not saying that domain
signature is equivalent to a domain, but somehow two users with the same
domain signature necessarily implies that there must be a direct
connectivity). So we concluded that the best way to figure this out (direct
connectivity) is to try directly, i.e. by pinging the other end point at the
address/port at which it likes to receive media. And, since there'll be
retransmission involved, we would like to allow the call setup progress
independently. Also, a mechansim using STUN (and only STUN) would allow
other session protocols make use of this mechanism. As Cullen pointed out in
a separate SIPPING thread, this may not be STUN per se, but a kind of STUN
PING based on STUN (since it would use many of the same STUN parameters &
properties).

    Thanks,
    Sanjoy

      -----Original Message-----
      From: Medhavi Bhatia [mailto:[email-masked]]
      Sent: Tuesday, October 01, 2002 9:54 AM
      To: [email-masked]
      Subject: [MMUSIC] suggestion for new parameter

      by by another proxy in the chain, who desires that media MUST be
routed

      When an offer containing this SDP reaches the final proxy (to which
the
      gateway/endpoint is registered), it determines using m0, that the src
      media is originaing in the same domain as the final destination. It
      removes the old m and c lines, and introduces new lines based on the
contents
      of the m0 line. This procedure can be done at the final destination,
if it supports
      the m0 parameter.

      Any comments ?

      -Medhavi.