Subject: [Sipping] SDP in draft-ietf-sipping-transc-3pcc-00

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Feb 2004 08:00:43 -0800

SDP is a scary place so using SDP to separate the SDP bodies for A and B is
scary. Consider the following use case:

I have a transcoder that takes a audio from a UA connected to a microphone
and another camera UA that sends video. I am going to feed both of these to
a transcoder and produce a single mpeg output stream that contains both
audio video. Here I need so specify that the input SDP has two IP addresses
and the output has one. This would be even more complicated if one UA did
the offer/ans in INV/200 while the other used the 200/ACK.

Also related to all this, would be nice to be confident that pre conditions
stuff worked while using all this.

Anyways, I like the overall solution to all this stuff. I wish there was a
better solution to separating the A+B, TA+TB information to the transcoder
than adding more semantics to SDP.

Cullen

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Tue, 24 Feb 2004 10:17:12 +0200

Cullen,

inline:

> than adding more semantics to SDP.

Previous version of this draft use to provide this information using SDP 
attributes, which were defined in the draft below:

http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-source-sink-01.txt

Nevertheless, the feedback we got from, among others, MMUSIC and 
SIPPING, was that we did not need those parameters. The Request-URI will 
indentify the service the transcoder provides, making unnecessary more 
information.

In your example, you would have a URI that indentifies the service 
(taking both inputs and creating the mpeg).

Thanks,

Gonzalo

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.