Subject: [Sip-implementors] problem in draft-ietf-mmusic-sdp-comedia-00?

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jun 2001 14:30:12 -0400

I believe there are some problems in draft-ietf-mmusic-sdp-comedia-00,
at least when used with SIP. I made a posting to sip-implementors
earlier but got no responses, so I will try here.

Consider an endpoint like a gateway that might be establishing many
connections simultaneously, and assume it wants to act in
direction:passive or direction:both. To do so, it hands out SDP
specifying the port number it will listen on for connections. If it uses
the same port number for multiple concurrent connections, then it will
have difficulty in telling which incoming connection belongs to each
pending call. (This is essentially the same problem that section 3 -
Source-Port Considerations attempts to address, but the problem is
actually a larger one that the draft doesn't address.)

The <source-port> is supposed to make it possible to sort this out. But
that can only distinguish between incoming connections from the same
address - requests from different addresses could be using the same
port.

Perhaps the draft assumes that the connection will be from the c= in the
sdp from the other endpoint. But that is a pretty shaky assumption.

The only certain solution I can see without changing the draft is to
dedicate a listening port for the duration of a single invitation. But
this is a costly solution. Alternately, the syntax could be extended to:

       a=direction:<role> <source-port> <source-address>

I believe this would solve the problem if <source-port> and
<source-address> are provided. Ensuring this would require making them
mandatory rather than optional as currently specified.

	Paul Kyzivat
	Cisco Systems

---

From: David Yon <[email-masked]>
Date: Fri, 08 Jun 2001 17:49:50 -0400

The crux of the argument here appears to be that:

         (a) I can't trust the IP address given in the SDP, therefore
         (b) the port number is not sufficient to identify the endpoint.

On the face of it the above is true, but it begs the question of why you 
wouldn't trust the IP address.  The only reason I can think of is when the 
other end is behind a N/PAT router, in which case you can't trust the port 
number either.  All bets are off at that point, and to make the network 
topology work you really need to have a SIP-aware N/PAT engine (or one that 
is cooperating with the local SIP proxy to rewrite the SDP to accommodate 
the public/private addressing).

I would submit that is is not a goal for comedia to solve the N/PAT 
problem, and that in the case of non-manipulated addressing the 
IP/Port-IP/Port pair is sufficient to uniquely identify the session.

If N/PAT was not the scenario you were considering, could you elaborate 
more on issue?  Thanks!

>mandatory rather than optional as currently specified.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063
Voice   +1-603-577-8708 x206
Fax     +1-603-578-9564
[email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jun 2001 18:46:47 -0400

Response below

	Paul

> If N/PAT was not the scenario you were considering, could you elaborate

No, the point isn't that I can't *trust* the address given in the SDP.

One point is that the address my listener is at may differ from the
address that I might connect from.

It isn't apparent (to me) if the proposal makes this assumption or not.
If it does, then at least I can stop worrying about how to make things
work on the listening side if it isn't true (which is what I have been
doing), and instead start worrying about how to ensure that I connect
from the same address I listen on.

Another point is that the c= line may not uniquely identify a connecting
endpoint.
What if the direction:active endpoint is redundant, and provides a c=
with a DNS name that maps to multiple addresses? Does the
direction:passive endpoint accept a connect from any of the addresses?

---

From: David Yon <[email-masked]>
Date: Mon, 11 Jun 2001 08:43:30 -0400

>address that I might connect from.

Why would that be the case?  There is no parallel in the traditional usage 
of SDP where RTCP/UDP streams are being described.  The IP Address you 
advertise in SDP is the address at which you intend to communicate.

>direction:passive endpoint accept a connect from any of the addresses?

A DNS name is not valid in the "c=" line---it must be a specific 
address.  Check the SDP spec for details:

http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp-new-02.txt

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jun 2001 12:20:58 -0400

> advertise in SDP is the address at which you intend to communicate.

I disagree. There has been a fair amount of discussion on this subject,
on the sip-implementors mailing list I believe. Consider the case:

   User A                  User B
     |                        |
     |       INVITE F1        |
     |----------------------->|
     |       200 OK F2        |
     |<-----------------------|
     |         ACK F3         |
     |----------------------->|

with (simplified) message detail as follows:

   F1 INVITE User A -> User B

   INVITE sip:[email-masked] SIP/2.0
   From: BigGuy <sip:[email-masked]>
   To: LittleGuy <sip:[email-masked]>

   v=0
   o=UserA 2890844526 2890844526 IN IP4 here.com
   s=Session SDP
   c=IN IP4 100.101.102.103
   t=0 0
   m=audio 49172 RTP/AVP 0

   F2 200 OK User B -> User A

   SIP/2.0 200 OK
   From: BigGuy <sip:[email-masked]>
   To: LittleGuy <sip:[email-masked]>;tag=8321234356

   v=0
   o=UserB 2890844527 2890844527 IN IP4 there.com
   s=Session SDP
   c=IN IP4 110.111.112.113
   t=0 0
   m=audio 3456 RTP/AVP 0

The address from the c= in F1 plus the port in the m= says that User A
expects data to be sent to 100.101.102.103:49172, while F2 says that
User B expects data to be sent to 110.111.112.113:3456. But I am quite
sure I have read that User A should not expect or require the sender of
the data it receives to be 110.111.112.113:3456, and visa versa. (I
would have to hunt to find the particular mail messages that discussed
this.) The essence of the discussion was that making this assumption
would place unreasonable architectural limitations on sip user agents. 

I made the conceptual leap (perhaps unjustified) that the same reasoning
applies to the passive and active ends of a connection oriented media
stream. Namely that the socket my UA listens on (when acting passively)
may be at a different address than the socket my UA connects from (when
acting actively).

This would mostly be relevant when an endpoint that specifies
direction:both acts actively by connecting. In this case the address it
provided in c= must be the address of the listening socket.

> >Another point is that the c= line may not uniquely identify a connecting endpoint.

Hmm. That is a change from rfc2327. I admit to not having been following
the proceedings here in mmusic, but apparently I am not the only one -
draft-ietf-sip-call-flows-04 is filled with c= lines using FQDNs.

What was the reason for the change?

	Paul Kyzivat
	Cisco Systems

---

From: David Yon <[email-masked]>
Date: Mon, 11 Jun 2001 13:45:49 -0400

Ok, now that I understand the issue the points are well taken.  I have no 
problem with the notion of extending the new direction attribute to include 
an IP address so long as it is optional.  The shorthand BNF would be as 
follows:

    connection-setup =    "direction" ":" direction-spec

    direction-spec =      "passive" | qualified-direction

    qualified-direction = direction-ident |
                           direction-ident port |
                           direction-ident address |
                           direction-ident port address

    direction-ident =     "both" | "active"

So if the address is missing, then the assumption is that the address that 
appears in the c= line will be used to initiate an active connection, 
otherwise it is the address listed in the direction attribute.

If anyone has any problems with this feel free to speak up, otherwise I'll 
add this to the draft for inclusion in the (hopefully soon to be called) 
Last Call.

Re: FQDN vs IPv4 addresses, I have no insight into why it is different from 
rfc2327 to the draft I pointed you to.

David Yon
Chief Technical Officer
Dialout.Net, Inc.
402 Amherst St.
Nashua, NH 03063