Subject: SIPv3 (and SDP) comments

From: Koskelainen Petri <[email-masked]>
Date: Wed, 27 Aug 1997 11:29:12 +0300 (EET DST)

Hi,

Having read SIPv3 draft I have still two questions.

1: Is it possible for a receiver (SIP server) to select to 
which port media stream is to be sent by sender (SIP client)  ?
Now I assume that sender decides (guesses?) it and there is no
corresponding warning message (example: "606.6 Port not available")

I think such a feature is useful since receiver may want to control
that or selected port might be in use already.

2: Is it possible to exchange codec options via SIP ?
Many codecs have codec-specific options. 
How can this codec specific information be presented in SIP message ?  
 
SDP a=rtpmap attribute seems not to be proper place to do this 
since SDP draft says:
 
    Additional parameters may be  defined  in  the  future,  but  codec-
    specific  parameters  should  not  be added.  Parameters added to an
    rtpmap attribute should only be those required for a session  direc-
    tory to make the choice of appropriate media too to participate in a
    session.  Codec-specific parameters should be added in other  attri-
    butes.

How about a=fmtp attribute in SDP ?
Is that the right place to specify codec specific options ?

If yes, where are these format specific parameters defined ?
In AVT/MMUSIC/ITU/IANA etc ?

/petri

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 27 Aug 1997 18:51:44 -0400

> Having read SIPv3 draft I have still two questions.

Just to avoid confusion: this is SIPv2, draft -03.

> corresponding warning message (example: "606.6 Port not available")

This will be clarified in the working draft, but the basic model is that
each party declares where it wants to receive data and the sender
obliges by sending to that address and port.

> How can this codec specific information be presented in SIP message ?

This is the role of the session description format, SDP or otherwise.

> In AVT/MMUSIC/ITU/IANA etc ?

If this is an RTP payload format, they may as well be defined in the RTP
payload definition, to avoid proliferation of two-page RFCs. I'm not
aware of any formats that do that, though. None of the standard payload
types so far seem to need these parameters, although they are discussed
frequently.

-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 908 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 
0027         URL:   http://www.cs.columbia.edu/~hgs

---

From: Colin Perkins <[email-masked]>
Date: Thu, 28 Aug 1997 11:59:33 +0100

--> Henning Schulzrinne writes:
>-->Koskelainen Petri wrote:

The RTP redundancy payload (draft-ietf-avt-rtp-redundancy-01.txt) does
this. We use the "fmtp" attribute to indicate which codecs should be used
when sending redundant data.

-- 
Colin Perkins                   Email: [email-masked]
Department of Computer Science  Phone: (+44) 171 419 3666
University College London       WWW  : http://www.cs.ucl.ac.uk/staff/c.perkins/