Subject: RE: [Sipping] Tunnelling QSIG over SIP

From: "Elwell, John" <[email-masked]>
Date: Wed, 04 Jun 2003 12:07:51 +0100

Rohan,

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.

John Elwell ([email-masked])

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: 03 June 2003 22:37
> To: Elwell, John
> Cc: [email-masked]'
> Subject: Re: [Sipping] Tunnelling QSIG over SIP
> 
> 
> 
> On Monday, June 2, 2003, at 06:31 AM, Elwell, John wrote:
> 
> > I am exploring ways of tunnelling QSIG over SIP making use 
> of the MIME 
> > type
> > already defined for this purpose. One scenario of interest involves
> > significant QSIG traffic between a given pair of gateways, and to 
> > support
> > this efficiently a single SIP dialog is used to transport 
> multiple QSIG
> > calls. The dialog would be established on a semi-permanent 
> basis and 
> > QSIG
> > calls would be established and released on demand over this dialog.
> >
> > The main difficulty is the fact that each QSIG call will require a 
> > pair of
> > RTP streams and therefore call establishment or call clearing will 
> > require
> > an update to the session description (by means of UPDATE or 
> > re-INVITE). The
> > question is how to represent the session, which at any instant will 
> > comprise
> > n pairs of RTP streams, and relate these streams to QSIG channels. A
> > possible solution is to use multiple m= (typically m=audio) lines, 
> > where the
> > first m= line corresponds to channel 1, the second to 
> channel 2, etc. 
> > The
> > last m= line would correspond to the highest numbered QSIG 
> channel in 
> > use.
> 
> rather than using specific m-lines, you could use the flow, 
> group, and 
> media-stream id concepts defined here:
> 
> draft-ietf-mmusic-fid-0?.txt  (i'm on an airplane)
> 
> thx,
> -r
> 
> > Any unused channels within the range would be marked as inactive
> > (a=inactive). This convention would need to be understood 
> only by the
> > gateways concerned.
> >
> > I would welcome any comments on this proposal, or any alternative 
> > solutions.
> >
> > John Elwell ([email-masked])
> >
> > _______________________________________________
> > 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
> 
_______________________________________________
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