Subject: RE: [Sipping] Tunnelling QSIG over SIP

From: "Gonzalo Camarillo Gonzalez (LMF)" <[email-masked]>
Date: Thu, 5 Jun 2003 13:47:44 +0200

-----Original Message-----
From: Elwell, John [mailto:[email-masked]]
Sent: Wednesday, June 04, 2003 2:08 PM
To: 'Rohan Mahy'
Cc: [email-masked]'
Subject: RE: [Sipping] Tunnelling QSIG over SIP
John,

>Thanks for this information. The draft concerned has now become RFC3388. The
>grouping defined there is applicable only to streams requiring lip synch and
>flow identification. The latter is explicitly not intended for parallel
>encoding.
>
>However, the MID (Media Identification) attribute may be a way of
>associating a media stream with a QSIG channel, rather than relying on the
>order of m= lines. This would also eliminate the need to keep m= lines for
>channels that are no longer in use, and therefore the number of m= lines
>would always equal the number of active QSIG channels.

The grouping framework defined in RFC 3388 allows you to group any number of m lines for any purpose you want to define. However, if you want to change how the offer/answer model works, using mid attributes to map media lines rather than their position in their SDP, you will have to define a new option tag (for Require). Otherwise, user agents that did not support this extension would become confused pretty soon (e.g-, after the first re-INVITE).

Gonzalo
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 5 Jun 2003 09:24:33 -0700

On Thursday, June 5, 2003, at 04:47 AM, Gonzalo Camarillo Gonzalez 
(LMF) wrote:

> The grouping framework defined in RFC 3388 allows you to group any 
> number of m lines for any purpose you want to define. However, if you 
> want to change how the offer/answer model works, using mid attributes 
> to map media lines rather than their position in their SDP, you will 
> have to define a new option tag (for Require). Otherwise, user agents 
> that did not support this extension would become confused pretty soon 
> (e.g-, after the first re-INVITE).

Alternatively if you wanted to maintain backward compatibility, you 
could leave unused m-lines in the session description but set to 
a=inactive: and with no mid/fid.

thanks,
-rohan