Subject: SIP and RTP correlations

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 21 May 1998 10:53:30 -0400

I believe there is a need to be able to associate RTP packets with the
SIP address of the entity which generated them. There are a few examples
of where this is useful:

1. In a multicast conference, you hear audio from someone and want to
invite them to a side conference using SIP. 
2. You sent out a SIP INVITE, and got two 200 responses, both of which
are ACK'ed. The caller now receives audio from both sources to the same
port. How does it know which RTP stream is associated with which SIP
entity? Such correlation is needed for various UI features.

There seem to be a number of possible solutions:

1. Include the CNAME as a header somewhere in the SIP INVITE message or
SDP. This solves problem 2 above, but not problem 1.
2. Include the SSRC as a header somewhere in the SIP INVITE or SDP. This
also solves problem 2, but not 1. It has the additional drawback that
SSRC are not fixed, and may change due to a collision.
3. Use the EMAIL SDES item. For problem (1), you would send a SIP invite
to the address listed in the email identifier. For problem (2), the
email identifier could be matched with the contents of the Location
header to perform the correlation. The problem here is that SIP
addresses need not be the same as the user's email address.
4. Add a new SDES item, called SIP-CADDR, which contains the user's SIP
address. The ITU folks did a similar thing for H.332; they have
registered an H.323-CADDR type used for solving problem (1). 

Comments or other possibilities?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 21 May 1998 11:43:27 -0400

> registered an H.323-CADDR type used for solving problem (1).

Only solution (4) seems generic enough, and we definitely want to avoid
making SSRCs visible outside RTP as much as we can. Given the bandwidth
limitation of the RTCP channel, allowing re-use of the same identifier
is helpful, since having

H323-CADDR: foo@bar
SIP-CADDR: foo@bar
WhitePine-CADDR: foo@bar

is very inefficient, in particular since it is likely that many of these
addresses are going to be of the user@host variety. We could use
something like

CADDR: {sip,h323,whitepine}:foo@bar

or a binary equivalent.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 22 May 1998 14:44:32 +0100

>Jonathan Rosenberg wrote:
...
>CADDR: {sip,h323,whitepine}:foo@bar

Could we use the CNAME? Put a sip: url in there? The media tools will have
to be modified anyway, to send out SIP-CADDR. This also avoids having a
proliferation of sdes packet types...

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 22 May 1998 10:56:57 -0400

> proliferation of sdes packet types...

I don't think CNAME is appropriate, since it identifies the actual host
the data is coming from. In many cases, I want my SIP requests to go
through various proxies (that do call filtering, firewall drilling,
etc.). Also, we want to maintain backward-compatibility, and CNAME is
the one crucial piece of RTP SDES information that applications rely on
for grouping.

Also, it is sufficient to send the SIP URL in one media stream, while
CNAME is clearly needed everywhere.

-- 
Henning Schulzrinne   [email-masked]
Dept. of Comp. Sci.   ph  +1 212 939-7042
Columbia University   fax +1 212 666-0140
New York, NY 10027    http://www.cs.columbia.edu/~hgs

---

From: "daveh" <[email-masked]>
Date: Sun, 24 May 1998 09:10:16 -0500

Remove [email-masked]